Hello everyone, and welcome to React Round Up, the podcast where we keep
you updated on all things React related. We have a bunch of new hosts
in the show, so this is going to be fresh for all of you
that are listening us for a very long time. And yeah, let's get
into it. So this show is produced by two companies, Stop and Doves
and Onvoid. Pop and Doves is where we create top and dows so get
top and pay and recognition while working on interesting problems and making meaningful community contributions.
And Onvoid which offers remote design and software development services on a performance basis,
so clients only pay when tasks are delivered and approved. My name is
Lucas Paganini. I'm the founder of Onvoid and one of the hostess in the
podcast today and joining me in today's episode is first the one and only Charles
Maxwood. Yeah, old host, same as the new or new host,
same as you. I started the show way back when and uh yeah,
helped post it for the first three years. So anyway, I'm back.
Good to see y'all. The king is back, yeah, and we also
have some new faces around here. Well, my voice is probably new to
a lot of people, but we also have Peter Osa. Yeah, hello,
everone, so nice having nice nine Misten everyone in the panel list.
Yeah, it's great to talk about reactuff. It's you all. Yeah,
great to having Peter. And we also have Chris Fruan yep Hi. Everyone
super happy to be here, Very excited to get into this episode and future
episodes. Awesome, awesome. Okay, so we have very high cal of
our professionals here. They're probably all smarter than me, so I'm going to
introduce the topic and rely on their intelligence for us to really have that into
this episode. So we were discussing talking about how we deploy or single page
applications. Of course we're going to talk more specifically about REACT, but I
imagine that a lot of what we're going to talk about here today is going
to apply to a lot of folks who are using other frameworks. So you
might be using View or anything. Actually, really any single page application framework
would probably benefit from the things that we're going to discuss here today. And
yeah, so we're going to talk about how we deploy our single page applications.
So I'm going to just get things rolling and say that thus far,
I've been a very happy, heroical customer for the front end. I don't
think Heroical is the most costive effect alternative, but it is so easy to
get things deployed into Heroku. There are many other alternatives that also make it
easier nowadays. But I know that I sound young, but I'm actually quite
old. So back in the days, Heroica was the easiest one and the
other ones were not as close as easy as Europa, and I just stick
to it, so I think it serves me well for most projects. But
I've been looking a lot into cloud Flare cloud Flare pages because it's a servilis
alternative, which means that I don't first if my website isn't being accessed as
much, I don't have to pay for a dedicated server, which is a
problem that I have currently with Heroku. Even if like my super old website
is not being accessed anymore, I'm still having to pay for it, which
I think could be a better use of my money if I could spend it
somewhere else. So I would like to pay on a performance basis. But
also I can't also have scalability issues because if I really have like millions of
users trying to access my website at the same time, I'm gonna have to
go into Heroko and increase my dinos, which is the name that they give
to the servers. But if I go with a Servil's approach, I don't
have to worry about scalability at all. So that sounds really interesting to me.
I gotta be honest, I haven't migrated yet, but I'm really interested
in the benchmarks I've seen so far. And yeah, I wanted to know
what is the experience that you guys have with that, and if you think
that this would be a good move or if I'm setting myself for failure if
I go that route, My experience is totally different, So I'm curious what
Peter and Chris have to say. So experience, Yeah, hero cool,
Yeah, Yeah is very great. Yeah, like I'm actually it's actually very
awesome. Although yeah, but I'm kind of like a fan of like Netli
five or just starting pages, so I think I'm that kind of guy.
So just okay, once I get once I connect notified to my ripportor and
just build the application and then boom. Also, I just love how how
simplistic it is. Yeah, and then there still the old fashioned way of
GiB and trying to do some configurations on how to set up like spas and
how to kind of like build it and then push it up to the top
pages. But they, yeah, take away bit bias to netli Fi and
then Heal came along, so I'm still find of visual as well too.
It's kind of very easy, especially for next year's applications. So it's just
so so easy. Yeah, I think, well, in yeah, I
when I started with when I then with SPS, I kind of if you
look at you kind of fleet for a little projects, so kind of Jeyted
as well. I found then I think subsequently then I found Metlify and then
Stevins. Yeah, so Chris, what do you think? What do you
think? Is like, yes, so actually I are more on page with
you. I'm also a huge Netlefy fan. Typically, like when I write
about it or talk about it, I always say that it almost feels like
stealing because they they're so generous with the build time and I think you can
have I don't even know if there is a sight limit, but it's just
it's yeah, they make it super easy. With that said, though,
I I did start also back back in the days like like Lucas on Heroku,
and I think, at least in my mind or what I remember,
Heroka has a more you have like access to your terminal and everything, which
you maybe have as well with Netlefy, but loves much more. I think
it's much more for maybe someone who is more like a more like a CIS
admin type person where it's really like point and click, whereas Roca you can
kind of drill down and get more into the technical stuff. But yeah,
like you Peter, like, I think I moved away because I think I
believe they took away the free tier entirely not too long ago. Yeah,
yeah, I think that's kind of missed everything. Like there's so many guys,
like I know, so many guys were like, oh you want the
lovely look. They just want to spin it for a little side project you're
working on Boom the freeta was going and we're like, oh no, and
then start seeing the cell and other options and yeah, the joke on it.
So I think that was kind of like the main in Guns for Men,
because yeah, it was, it was really nice. Like the it's
filthality for small projects like Ebody for Reactor for even might not just back in
projects little projects like you just spin it off. Yeah, but I think
that was like what do you think, because do you think did the foods
affected any of its use at any point? Oh? Man, you really
needed to go there right like that. I was almost closer. Yeah,
you're right, I did felt that. I just felt that I know that
we're not supposed to rely on free stuff. I mean, there's always somebody
doing the work, so if we really want to use it, we should
be paying something for the value that we're getting. But honestly, they made
me used to the free servers, and then when they took it away,
I was like, oh, come on, like, there's so much that
we're gonna have to pay now. But one thing that I really like about
Heroku is that it allows me to push entire doctor containers. I don't know
that's an option for Netlify, because, as you said, I always saw
Netlify as more of a platform as a service. So as you were saying,
it doesn't give me much control over the infrastructure, which it might be
just a misunderstanding from my end because I haven't really used netlified that much.
So I don't want to put a Netlify in a position of saying Hey,
lookas everything that you're saying is wrong, because it might just be. I've
never used it for production applications, but I know that Heroico allows me to
push Doctor containers, and I really like that because I tend to always containerize
everything that I'm doing, even if it's just the front end, even just
front end applications. My experience has always been to containerize it as much as
possible. It just makes all the other parts of my continuous integration pipeline easier
to do because if I can containerize my application, then I can just substitute
one project for the other and reuse all the other setup that I have for
continuous integration, like running my and to and test with Cyprus and building and
serving, et cetera. So I really like that, and I really like
the consistency of knowing that if it's working on my local Doctor container is going
to be working the same way in the cloud environment. So I try to
stay away from those smart algorithms that you just like, integrate your GitHub repository
and they see that it has a package Jason, so they understand that it's
not then they automatically build and serve. I try to avoid that because I
am a freak for control, so I really I wanted to be sure of
what I was deploying. So yeah, I really like when I can just
deploy a doctor container. But I know that if I go into a server
list path, I won't be able to have that. So this is being
my current question, right, So would it makes sense for me to give
up control to have that speed and scalability and ease of serverists or do I
still want to have control and have doctor containers. And by the way,
one of the things that also make me want to have doctor containers instead of
just a regular static serve is because I almost always use Service I rendering,
and it's not always just a pre rendered or pre generated static website. There's
always some pages that are indeed dynamic and they need to be dynamically rendered.
So I can't just serve static files. I really need to have a little
bit more more power on the server to make sure that the pages that need
to be dynamically rendered are dynamically rendered on the server. So I don't know
if if that changes for you guys, if your experience is more like just
just relying on client side rendering, or if you also had this experience with
service I rendering and how you tackle that. So I'm going to jump in
because you made me feel less weird because we're all talking about, you know,
deploying to something like Heroku, which my first experience with Heroku was when
they initially launched, they were an online id for Ruby on Rails, and
then they pivoted and did the push to deploy, and so I've been using
Heroku for years and years and years and years. There are definitely things I
like about Heroku, but yeah, it's usually the cost that keeps me off
of it. I just I'm not willing to pay for it. I was
a SISS admin before I was a programmer, and so I'm pretty comfortable going
I'm just going to set up a server to run this myself, and so
I've done that before with the front end framework. Shoot have to do that
nearly as often, but anyway, what I tend to do is, yeah,
I tend to reach for Docker for my deployments. I'm tip typically writing
Rails and React. If I'm writing React, and so a lot of times
the deployment is effectively whatever build systems built into Rails pointed at my React files
and it just you know, it deploys it as part of the assets,
and so a lot of the deployments have just been you know, kind of
a standard thing, and you know, we've gone through all the stages where
you know, initially it just kind of, you know, put a digest
on your JavaScript files. This is before React. Once React kind of came
around. Then we had Webpack integrated with Rails, which was a huge pain
in the neck because Webpack and I mean it was better than the alternatives at
the time, but now we've got much better alternatives, I think than Webpack.
But yeah, so you would just when you deployed, it just installed
all the libraries for Rails, you had note installed on your server, It
did the build, it put it where Rails could find it, and then
you just pointed your app at that and then it would hit your APIs on
your Rails app. The other thing that I'm starting to get into now,
and this is part of launching the React Geniuses, which is going to be
the video series and the meetups, is I want to build apps in kind
of the big major frameworks, and so I've started playing with Redwood JS and
I'm still of the opinion that i want to do most of this with doctor
containers, and I've been using the new Rails tool for that and it's called
camal and effectively, what it does is you have docer containers that are built
with your app in it, and so it knows how to build, right,
which is what Lucas is talking about. But the difference between using it
to push to something like Heroku versus using camal is you go and you set
up servers on Digital Ocean or linod or something like that, and then what
it does is it actually logs into that machine, it installs Docker on it
if it doesn't already have it, and then it updates the images for you
as you go. And so then you deplay it, you have your secrets
on your local dev machine, you push it all up, it does the
thing. There's also a way to integrate that with like one password if you
want your secrets in one password, and so yeah, so it does all
the build and push and deploy and everything like that, and so that that's
kind of the way that I've been rolling lately. I will say though that
it's really nice to playing something like netlafire ever sell where they have kind of
the they know how to build these apps, and so effectively, what you
wind up doing is you say push it up to Versell, and Versell says,
oh, I know what to do with this, and it builds it
for you. And so then you know, unless you've got something a little
bit different going on outside of the norm, which most people don't, it
just happily does it for you. So there are definitely trade offs. The
Heroku thing is another. If you don't want to fuss with your server setup,
right, they manage all that stuff, I wind up The only other
drawback I guess th Heroku versus some of the other ones is that I feel
like I wind up paying for Heroku and like six add ons on any app
that I run on it. And so if I yeah, but I've been
doing contract work. So if I have a client, right who isn't going
to pay me ongoing whatever to maintain their app, then Heroku is actually the
way that I go because then nobody has to figure anything out, right if
they if they have a problem with it running and I get hit by a
bus, they can call Heroku and say my app isn't running Heruku may be
able to help them out. So anyway, that's kind of the long and
the short of how I do deployments, which is different I think than most
of the people in the React community. Yeah, one thing I also wanted
to say about things like netlefi. Ninety nine percent of the time you can
just rely on. However, they're, like Lucas said, they're reading your
MPM. But if you really want to get into the weeds, they have
this this TOMIL file and you can define I mean, you can't do everything,
but you can define quite a few things like if you need I don't
know, if you if you change domains or something and you need some custom
redirects. And I actually needed it recently. It wasn't in the TOMIL file,
but one of the environment flags because so I'm a primarily a Gatsby guy,
so not not quite a SPA, but you know, building multi page
sites with React, it's quite a big site, and I needed to bump
like, there's a built in environment variable for the memory that it uses when
building, so I needed to bump that up. But yeah, I face
that too, Okay, Yeah, and but yeah, I would wonder.
Uh, I don't believe you can do darker anything like that, but I
don't know. Maybe Peter could speak a bit to that, but I don't
have experience with that, just just with a tune of file. So yeah,
I don't think it starts much like ability kind of. So it's just
mostly I think that's where he cartually shines, and I think, yeah,
Charles Mitchells come out, yeah, and it's really actually interesting. I think
I read it for me boost from yeah, the creator of the blower.
I think it's yeah, I don't forget his name, Chris also yeah,
so it's actually nice too. So but apparently I think one thing about why
I actually preferend that I think it's based on my use kis so most of
the time I usually like to bundle, like just show my applicasions are just
like static. So if if I'm maybe trying to do some other kind of
gymnastics or whatever configuration, I I just I just limit it to that kind
of thing because I actually feel maybe it's best to just bound the digitals,
just build it and bonded it and then just push it up. So I
think it's just my philosophy though, so I'm really not simply key. So
most of the time they may be usually cases for me to actually just you
know, try to explore or maybe the options, but I think it's just
based on how I handle think about the ocation. I just want to build
it and just yeah, maybe it's something someone can just go this is the
five, push it to vessel, push it to the five something. It
just is obvious in my own opinion. Yeah, I don't know if you
have any Oh yeah, so look, as I think you said something about
the using like for all your projects using DOCA, Like you always docker as
your applications to put front and on. So is it do this for all
the applications, both your side projects or you company projects, So like,
I just want to know if it's for all the applications you work it's just
for specific types. Okay, so actually it's for all of them. I
don't remember any project that I haven't containerized everything. Yeah, yeah, it's
for every project. It's sort of company projects. For personal projects, I
always containerize everything. There are definitely some projects I've worked on in which I
was not the person that did the architecture and they were, uh, they
were not containerizing the front end, which I just left it as it is
and worked in the way that they that they were already doing it. But
every time that I had control over the architecture, I went to the route
of containerizing it. But now like, so, okay, my back ends
are always definitely going to be containerized. I don't see myself migrating the back
ends in which I'm architecturing to like a fully serverist approach or something like that.
I really think that there's much more benefit in containerizing the back ends and
having that level of control over the back end because it's generally not as straightforward
as front and builds in front end deployments. Also, that makes sense to
me. I primarily do back end. That makes a lot of sense to
me. Yeah, yeah, I think for back ends the new BUNA you
just have to, I feel. But I actually am reconsidering my position on
that for the front end because in the back end, I generally don't have
a single monalytical application in the back end like sometimes I do. But in
other cases I have a bunch of micro services and I want to deploy them
and orchestrate them in the cloud. So of course it makes a lot more
sense to use doctor containers in that case and containerize the entire thing and don't
use a platform that it is so simple in that sense that doesn't give you
all the control that you want to orchestrate and take care of the scalability of
your back end. But it's like it's not even the same chart. Right.
If you think of the chart of how your application connects, and you
think about every piece that makes the back end work, they're really not connected
to the front end. Like they are completely separate environments and separate servers.
And for the front end to scale, we really only need to put a
low balancer and throw as many servers as we want because we're never gonna do
multiple services or micro services for a front end server. Why would you ever
want to purchase that complexity just to serve a front end, Right, So
this is why I really think that front ends are an excellent, excellent candidate
for serverists, because every single drawback the server licet has is irrelevant for front
end deployment. Like what I see people complaining the most about servertists is the
difficulty to debug and to see what's going on, to understand the flow of
data. And also it comes to a point where you're deploying four hundred Lambda
functions and you're just crazy trying to understand what's calling what. But if you're
going to deploy front end using serverle lists, then you're just gonna deploy one
function into one cloud environment and that's it. You're done. You're not gonna
do anything else besides that. So I actually think I'm doing in it wrong
in terms of front and the deployment specifically, But for back in I would
I would definitely keep the structure that I have. And by the way,
just one note check you're mentioning the costs of Heroku add ons. I never
used any Heroku add on. I always used other options. And what I
really like about Heroku is that they don't have their own data centers. I
know that might sound really weird, Like what I like the most is the
fact that they don't have something. But the thing is because they don't have
their own like Digital Ocean has their own data centers, yes, because Heroku
doesn't. They use AWS, which is great to me because I can host
my main application in Heroku, but I can host my Radis and moguldb on
a WS and I'm not gonna have any latency because it's in the same data
center. So this is what I always did instead of using the Heroku add
ons I would I would plug everything else from AWS. So for example,
I may use Mongo Atlas, which is a managed service for Mongo deb and
you can host that on AWS. And I might use Radus Labs, which
is a manager. Oh, I see where you're going radis, and I
host it on a WS and then my main container is on Heroku, which
is also a WS, so I don't have to use the the add ons
from hero You just make sure you're in the same region, and then your
secrets point exactly the other services exactly, and so then Heroku just becomes a
harness to deploy or manage your main app and your accessories, which you have
to manage on your own anyway as exactly. Okay, so look in an
instance of changing regions, let's assume I don't know, maybe it is just
being been paranoid. Maybe there's a change of regions, and yeah, maybe
today you could just decide, oh, we know, we don't use the
doubles anymore. I just want to patonize maybe we know or something else on
the service just that instance, wouldn't that solution not? Yeah, because at
the end of they I can of be seck with like I'm just looking at
how spontaneous some changes could be. And so what do you think in that
kind of situation, what would you do if there's a change at any point,
maybe a massive change, we just start think about how to migrate out,
or how to look for a new solution or something. Great question.
I would definitely if that happened, I would definitely fully migrate to a w
AS, which is where all my other add ons, if we're calling them
adoms are. Yeah, I would definitely migrate to AWS. And they would
never do that out of the blue. They would definitely give us a lot
of a lot of previous notice before doing that, so we would definitely have
enough time to migrate. And I don't like that everything needs to be AWS.
Okay, Like, let me make that clear. I don't like the
AWS interface. It's so confusing. It's hard to explain to other developers on
my team. I think it could be so much simpler. Jeff Besis,
if you're listening to the show, please please, like you have so much
money, just hire one designer to make that simpler. Okay, So yeah,
I definitely think it could be way simpler, and they have done some
initiatives to simplify that like we have AWS light Sale, which is a direct
alternative to Heroku, where you can simply push one container and it's going to
take care of serving that you don't have to configure the DNS and a bunch
of other settings yourself. It's simpler. It's still not as simple as Heroku,
but it is way simpler than all the other ways in which you can
host an application on AWS. But yeah, if that happened, I would
migrate to a WS. What I really would like to do if I could,
would be to have my main application on Digital Ocean. And the only
reason why I don't do that, and actually one of the reasons why I
want to do that is the pricing, and the other is because Digital Ocean
has the simplest Kubernaties managed service out there. Like if you compare deploying Kubernetes
to Digital Ocean, a WS, Azure and GCP, I haven't compared that
to Lenode, which I think they changed the name to Akamai or something like
that, but I know that come I bought them. Yeah, so Digital
Otion is just so much simpler to deploy Kubernetes cluster and the pricing is a
lot more friendlier too. But I don't deploy on Digital Ocean because I would
have to get rid of Mongo Atlas, which is my managed service for Mongo
deb because Mongo Atlas only allows me to serve on a ws GCP or Asia,
and even if I put it in a very very close data center,
it's not going to be in the same data center. So I don't want
that actual latency. So I would rather have more complexity on my plate to
the to the play everything in the same data center, then using a different
cloud provider and having my dB in a different data center. Yeah, that
sounds that sounds nice. I think that's unsolid. Yeah, that's so.
But then I think maybe let's look for an instance, maybe going to consider
the cost for example, or yeah, let's ass you like, still the
same case case where the heroes decides to attract yours or you know, migrate
or Swish jounelers or maybe they want to patronat you know, then they just
fish to them. So if imagine if you're working on it, like you
putjet on a business, it's the example like the cost of migration and the
cost of kind of moving that yeah, I know, yeah, obviously costs
a bit with it because you know it's a business and so many things will
be involved. But then don't you consider that that would be also cost because
yeah, you have your switching doesn't tally it screen to affect the performance at
the point, so you just have to switch be moving from here to a
others. Yeah, so InStyle, it's not better to just use the dying
like the Adoms. Maybe you can moves on. You're okay, you're handle
the Adoms and so on, Like, I don't know what do you think?
I actually think the opposite. I think that if you use the heroical
Adams, then it makes migration much costlier because they're more locked into the platform.
Like, okay, I can only I can't use Digital Ocean because they're
not gonna deploy on the same data center that is my red disk containers and
my mom go de b okay, But I can choose from a ws Asia
and GCP and I can go to either of the tree. And because everything
is containerized, moving the application would be a breeze. And if it is,
if I'm already outside, because every project starts as a monolith, and
then if it really really needs then it becomes a micro service. So if
it's a micro service and is using Kubernatis is also pretty easy to migrate.
So if you're a single monalytic application and it's containerized, you can go to
any cloud provider that you want. It's very easy to migrate. If you
have multiple containers and you're using kubernatis still pretty easy to migrate. What I
avoid is every cloud provider specific solution. Like I would never advise for a
new project to use cloud Formation because now you're stuck with AWS. You now
a WS is to pricey. Any want to migrate to Azure or GCP,
you can't, Like you can, but like the migration is going to be
much harder because you have a bunch of orchestration rules that only work on AWS
because they're using their proprietary tool to orchestrate your attach. So the same goes
for the add ons. I would never use the AWS managed they don't have
reddits right, but they have an alternative to raddis that is like exactly the
same thing, and I always forget the name. I would never use that
because now I'm stuck with AWS. I would always use a managed reddis solution
that is not specific to a cloud provider, but that allows me to deploy
in whatever cloud provider I want, if that makes sense, And then if
I want to migrate, everything in my application is ready for them migration,
even my script to provision cloud resources. I always use Terraform for that,
so it's super easy to migrate. If you're using Terraform, like, all
your configuration is already and it doesn't need to be Terraform. You could be
using Pulumi like any infrastructure as code tool will do. The trick is just
having all your setup in your code base and making sure that you're not using
anything that is specific to that vendor, and any migration is going to be
easy as easy as it could be. Saying that migration is easy would be
a misunderstanding, but it's as easy as it could be. Yeah, that
sounds also so Charles, what do you think, Like, do you have
like any beta with you? Like? What do you think? I mean
a lot of it just depends on how implicated your application is and what you're
trying to do with it, right, I mean I've put some toy apps
up on you know, Netlify or what have you. But yeah, I
tend to agree with Lucas to a certain extent. I think there are certain
levels of how do we put it, like economy or whatever, that you
get from using the resources on AWS right in the AWS way like they designed
them to work together. But I also agree that, yeah, if you
ever have to move it, then yeah, you're kind of locking yourself in.
So I think I think there's a lot of it depends in a lot
of this stuff. I've also worked for larger companies that had their own data
centers right or had presence in data centers, and so then it was,
you know, provisioning resources was effectively calling the ops team and having them get
you a server. So yeah, that would Yeah, almost every time I've
been in that situation, it was more of a pain to get my resources
than it would have been if they had just said, here's your budget,
you know, go to AWS or whatever. But yeah, I'm also not
a huge fan of the big cloud providers for most apps because most of the
time what you're building out is pretty small and simple, and so you can
get away with a lot of things. And so anyway, I guess I'm
just putting a whole bunch of caveats around what Lucas pointed out in the way
he does things because yeah, you know, just just do what works and
evolve from there is kind of my approach. So you know, I'll add
things in. I don't generally use Mongo, so the Mongo Atlas isn't an
issue for me. But you know, I you know, I've been using
Postgress forever, and I've used the cloud hosted, and I've used my own
and it mostly just works. And so you know, Okay, it looks
like this, what's all this problem we're starting to have with scaling or accessibility
or whatever, And so you know, I'll pick up some other technology and
add it in. And uh, yeah, I think for most apps,
for most companies, small to medium businesses, you probably get away with,
you know, putting everything in on one server and just kind of running it
from there until you decide you need a service that does something different. How
about your thus cause yeah, yeah, so I'm I've done a few different
things that I am very guilty of just running like without any containers. So
I started, like my first back ends were like probably like I don't know,
twenty fifteen, twenty sixteen, so doctor was around, but by maybe
I don't know, for some reason, I didn't get into it working on
getting that because I do agree with Lucas, like, if you can get
your applications to this you know, this docrized standpoint, then yeah you can.
Really you could basically go anywhere, right or you know, if you
want your own service on premise in the cloud where you can move it around.
So we I experienced a little bit of that with the startup I was
working with the last two years and we were eventually going to migrate everything to
I think Google. We chose GCP I think due to price, and we
found the pricing best for what we needed. But like, yeah, that's
what we experienced. We said, well, okay, if we can dockrize
everything on our current server, then it theoretically should work anywhere. But with
what Juck said, it's it's funny because a lot of people, I mean,
it's fun to think about huge scale, right, like millions and millions
of users and you know what, you know, do we need load balancing
and you know, geographical servers and all this stuff. But it's amazing,
at least in my opinion nowadays. What you know we were doing. We
had go Lang as our back end I think Gin and with just like four
cores, you can handle. You can handle a crazy amount of request.
We had. So the startup was in Switzerland and they were on the their
version of Shark Tank, and so we we already had done some load tests
and stuff, but of course you're always unsure, like what's actually going to
happen when when the TV Aaron came. But yeah, it handled. I
mean we had like I think, like ten thousand new users and like we
didn't even hit I think fifty capacity on any resource like memory or anything.
So yeah, I'm definitely h I'm definitely a fan of It's like, yeah,
the right tool for the right job. I mean, of course I
would argue it would have been nicer like all the for my applications had I
docrized it in the beginning, because I think we all know that that like
when something breaks, you're sshing onto the server and doing some debugging and you
don't know exactly where it is. But with Doctor at least you have like
a starting point like okay, it's something in the container blow up or something
like that. So yeah, I guess I don't know really where I'm going
with that, but I think it's like start small and pick you know,
the resources and things you need, you think for the project, and you'd
be surprised how many how much power small resources can manage. Yeah, and
then go for there. Yeah, I like that. I like that,
And just to reater it. I know that we've talked a lot, so
I know we're close to start wrapping up the episode, but I really want
to make it clear for everyone that is listening and thinking, what the hell
are you guys talking about. I don't know anything about that, Like,
don't worry. My first deployment I think was a PHP my admin, you
know, so back in the day, so I didn't start out doing all
those crazy things to make sure that the deployment was as killable and as organized
as possible and super flexible to move around. And if you put that as
a requirement for your app to go live, if you don't have the expertise
to do that quickly, then you might just not go live ever, you
know, So just get things deployed grow from there. But if I could
give one advice is have that little voice in your hand saying and I locked
with my current provider yes or no? And what could I do to make
myself less locked in? I know stories of people that like they were using
companies that were using AWS and their bill was super expensive, but they had
everything organized in a way that was so easy for them to migrate to GCP
or Azure or any other cloud provider they that they didn't even have to because
they could negotiate with AWS a major price reduction. And if your company is
like super locked in into your provider, if you get to a point where,
like I'm investing a lot of money into the cloud provider, what leverage
do you have to negotiate? Where are you going to tell them, hey,
please reduce the bill or else I'm gonna stick with you. So that's
not very compelling, right. But if you say, hey, my entire
application is containerized. We're using Kubernatives to orchestrate, so we're not using our
proprietary technology. And plus even our cloud provisioning is already documented with Infrastructure as
Code tool, So would you like to give me some discount so that I
can stay with your platform, That's a much much better position to be in,
right. But this is like so far in the future, So far
in the future, you should not be worrying about that scenario when you're just
starting out a project. So start out with whatever you know is the best
you can do quickly, and then grow from there. But just be mindful
what you're growing. Be mindful of every decision that you make, because every
architectural decision that you make from the moment you start and what you're growing is
gonna make it easier or harder for you to migrate to a better cloud environment
in the future. So yeah, yeah, that's that's actually true to it's
actually past to consider. Like en showing that you're not kind of locked into
your vendor very important because most services, like for example, I actually referenced
David's post on his migration from I Think A Ways to the its own best
cloud I think thirty six six now. So I really loved that because I
kind of followed it down. I was kind of wondering, how like,
because the movesus. I know, I know a lot of people that used
hate the email sets and the like no downtime, they didn't experience much.
I was like, WHOA, did you guys really move like? I was
really fascinated about the fact usually they move usually could cast some setting things,
maybe customers complainer, the sarvice is down here, this and that, but
it was so smooth. So yeah, I think it's actually based on what
you said. So I think they ensure that they were not locked into their
window. So when they made them move, it was so easy to just
plug out and plug into down custom myself. So this wasn't really a big
bid for them, but you just move that And no, I don't think
any of the customers just noticed that until they until the media announcement that I
hear we've moved, and I think I'm Charles. I don't know if you
followed the I think the meet up and think in the Netherlands or so will
be a waste away. Yes, also yeah, yes, exactly, and
we're like I think it was like a countdown where I think it was Fernando
someone and the seen those times to remove the last close the last like that
was really before Like I was like like wow, so much to pervision on
kind of thought putting into the code, so do able to just switch out
there was really no difficulty. I think they did it on stage. I
think Charles was probably basically kind of this a little bit it halfway. So
it's actually very vital that you don't become like vendor looped in so I think
I understand that very work kind of Yeah, what did it increase? Yeah,
I think it goes back to what Lucas mentioned too, like and what
you're saying is, yeah, this, this vendor lock can be a headache.
Also, like if you're a beginner, don't don't worry about it,
but as you build your stuff. I think a big part of this could
be perhaps its own episode about like some of these doctor is documentation. Right,
So even if it may seem trivial something small, but I'm telling you
now, I know from experience, if you forget like oh yeah this this
service here talks to this service and you only remember that by seeing when the
bug shows up. Yeah, so document you know these whatever it is interfaces
or how how services talk to each other, because that helps so much and
would hopefully lead to these these much smoother transitions between vendors. So yep,
that was a lot. I think we can start wrapping up before we get
to two hours of Actually, if I may say, just one last thing
regarding this subject is vendor lock in is not just about cloud providers, you
know. For example, recently I was thinking about links that I had in
some of the projects, like when you have links pointing to external services.
For example, a lot of companies use Calendly, for example, to handle
the bookings. You know, so Calendly is going to generate a scheduling link.
If you put that link directly into your website and you use that in
your emails and your documents, et cetera, you won't ever be able to
change that link. Ever, Like if you want to change the system that
you're using to book their meetings, you can't because you're going to be worried
about every single sales material that you're sent in the past with the previous link.
So even for that, it makes sense for you to think about vendor
lock in. You know, it's even in those scenarios. And in that
case, what you could do is use a link management system and then you
could have like a vanity link that redirects to the tool that you're actually going
to be using, and then if you ever want to migrate, you can
just migrate where the link is pointing. But yeah, these are just things
that we need to keep in mind as we're building our system. So it's
not just locked into your cloud provider, it's being locked into any external tool
that your company depends on and think about how would you handle a migration to
another tool if you ever need to face that situation, because I'm telling you
you're most definitely going to face that situation. The only scenario where you're not
gonna have to worry about migration is if your company dies. So you don't
want to prepare for that scenario, So you better prepare for the scenario where
you're going to need to migrate. Okay, let's start wrapping up. So
let's just do a quick round of promos and then we can close. Or
you may need to explain what you mean by promos. Oh yeah, that's
true because we didn't have promos in this show before, right, So pros
is our shameless way to talk about the things that we're working on and promote
our stuff so that we can convert some of you beautiful people that are consuming
our free content into maybe followers on our social medias or customers in some of
the projects that we're working on. So this is the promos section. Check
do you want to kick things off? Sure? So I've been jumping back
in a little bit on the React stuff, so top end devs, I'll
try and keep this really brief, but it's hard anyway. So top End
Devs initially we just did the podcasts, and then as I've talked to people
over the last years, it's become pretty apparent that some people are just getting
stuck in their careers. Now. A lot of the people that I talked
to that don't know what to do next or new right, and so they're
just like, what do I do? And it's like, just keep learning,
you know, keep moving forward, keep you know, meeting people.
But then I talk to people who have been doing this for two, three,
four, five, ten years and they're like, where do I go
from here? Right? And so top End Devs has I've kind of taken
it to that next place where it's like, Okay, let me help you
know what to do to get to that next level of your career, right.
And the principles still apply to newer developers. It's just that the fruit
is a little lower hanging for newer developers. So anyway, what we're doing
is I tell people that the three things you need to do in order to
take your career to the next place are build your skills, build your network,
and build your personal brand. And so we're putting together essentially systems for
people to use to build their skills. And so we're putting together meetups and
videos and courses and things like that right to build their network. We're putting
together three times a week for our different genius plans, which are going to
be React, JavaScript, uh Ruby, We're gonna meet three times a month,
and we're gonna talk about different stuff. So we may have somebody come
and present on something one of those weeks, but the other weeks we're going
to have more of a Q and A or open discussion, or we're going
to have you know, maybe members present or a networking session or something like
that, right where we bring in some of this other stuff. And then
for building your personal brand, we're also going to have content and courses about
building content, you know. And so for for me, the ones that
have worked best for me are YouTube and podcasting, and so that's where I'm
going to push people, right. I tend to pan the blogging. You
can make it work, but that's not really my cup of tea and I
don't think it's as effective. So anyway, so what I'm working on is
getting launched the Javascrip geniuses and the React Geniuses and effectively getting those meetup scheduled
and then start putting out the videos. And the videos are going to be
I'm gonna build this thing in React, right, So I may do it
in Redwood JS or Remix or next or Gatsby or something else, or maybe
I'll you know, I'll say, hey, I've got this custom back end
that I built in Rails and I'm gonna build the front end on it or
whatever, right, And so then we'll build different kinds of apps, and
that way you can see how some of these things go in It's rather frustrating
to me when I get in and it's like this tutorial on this toy app
that doesn't really have to integrate with anything, and so it works great there
and if I follow the steps, it works great for me, and then
I try and go and do it in real life and it's like it doesn't
work. So anyway, so React Geniuses is what's coming. I'm also just
going to toss out there that we're getting ready to launch the premium podcasts.
So if you want the podcast without the ads, you can get that.
If you want the if you get any of the others, So the video
series or the meetup series or both. Then you'll get access to the podcast
without the ads for free. So anyway, that's what I'm getting ready to
launch. We should have it up here within the next week or two,
so go check it out and that'll be at react geniuses dot com. Nice,
nice, awesome. So I want to send the link to it.
Here's a react genius dot com. Yeah, I'll put it in the comments.
It's not up yet, so it'll be up. My birthday is two
weeks from today. It'll be up by then. Okay, Peter, you're
gonna you're gonna say something. Yeah, I mean, that's very awesome.
Like I know a lot of people to actually need this, right because starting
out closed from my own experience starting out, it wasn't really easy because then
I wasn't kind of in the neighborhood where I didn't we have masters, developers
and maybe people help completely mantors you and so on and so forth. But
then with these I think this is agate with very nice for beginnails and people
are starting out. Yeah, I think this is a great it's important.
Yeah, yeah, I agree. A lot of tutorials are too into a
perfect universe and it ends up not being very realistic, So I appreciate the
thought that check is putting into making this more real world experience. All right,
So my proma is going to be on Void, so is you n
Void dot com And they offer all kinds of food tack software development services,
and we do that in a performance basis. The difference between that and every
other company that provides software development services is that in every other company, you're
going to pay by the hour and you don't really know how much value you're
getting from the But at Onvoid, you're only going to pay when the tasks
are delivered and approved by the client. So even if they are delivered and
the client doesn't like the quality in which they are or the code standards or
something like that, they can just ask for changes and it's only going to
become billable after the client says that they are adhering to a center to a
certain quality standard. So it's really the safest way for any company to outsource
or staff augment their software developments teams. And also, every single engineer at
Void works in the United States time zones, so companies don't have issues with
trying to talk to their engineers and they're being in a completely different time zone
and not being able to talk to them. So yeah, if you're interested
in that, or you know someone that might benefit from that, I highly
encourage you to check out Void dot com, you and oid dot com.
So yeah, how about you, Chris, do you have anything you'd like
to promote? Sure? Yeah, I'm a little bit probably stretched too thin
recently, so I'm just gonna keep it simple. I guess I would just
point people to my blog, Chrisfreut. I N I do have some other
products and projects hopefully coming out, but yeah, I guess following this theme,
what I really focus on in my blog is really how my blog started
is basically, whenever I would encounter anything at you know, I've worked for
startups or an industry and it was either really hard or like a bunch of
just trial and error that we all know, I would just be like,
Okay, I'm going to write a blog post about this and hopefully someone will
find, you know, if they ran it the same thing I ran into,
And this is how this is the solution I came up with. And
so with that, along with my blog, I have various courses so in
quite spanning quite wide languages and frameworks. I have some typescript courses. I
have a going course, and it's really focused on more. I mean,
of course you're not going to build an entire SaaS app, but they are
like I built a go course recently that's you know, how to deploy it
on doctor and get everything up and running like it was. It's like a
Crown Job service. So really trying to focus at integrating more than just one
thing and and what like some toy example. So yeah, by the way,
I highly encourage everyone to check out Chris's website just because it's so much
fun. I was just looking at it and there are just so many random
bits of rainbows and colorful things. It's just that's a cool personal website.
Dude, Like, that's really really cool. I like the as key computer
that you did on the left and you can actually click on subscriber or close
forever. I thought that was that was really well done. That's really interesting.
Congrats. Yeah, thanks. I'm a bit I've been kind of paranoid
recently because I've heard stories like because right now I only have dark mode,
I know, that's kind of like a bad practice, and people are like,
if I see a website like that, I won't even read it,
So maybe I have to bring back a light mode pretty much. And Benjamin
used to say that, Yeah. Nice. How about you, Peter,
Yeah, I don't really have much. Yeah, I think I write articles
for publications, so we'll find that day. And I think I was simply
lead to. So yeah, I just had publications, and I don't talk
about things constantly, react and soon, so just check we find that them
as well. Yeah, I didn't know if you've walked it. It's kind
of like he played nice work for building the act applications can spin off your
ain dashboards or b two the applications at one go. Yeah, so I
think it's one thing worth checking out. Let me just pist the link and
what is the best place for people to read your articles? Yeah? Many
of my LinkedIn Yeah, I just post them on my LinkedIn, right,
So I think my LinkedIn is correlated all my articles, so yeah, I
just passed them on my LinkedIn. I will share my LinkedIn profile as well.
So yeah, I just most of the time I'm there looking at all
some pos like maybe migration posts. Yeah, because I really enjoyed the series
of David Crital always migrating. Yeah, I just look at some of that
post and so on and so forth. So yeah, I think it does
cast me upon linkeding with my post. I think that works nice. Nice,
Okay, all right, everyone, thank you so much for joining.
It was a pleasure to meet Peter Chris Jack. I already know you for
a while, but it's always good to to to be on the show with
you guys. It was it was really nice. I really liked this this
format. It was a bit of a longer episode. We're maybe going to
try to keep it shorter in the next ones, but but yeah, I
really enjoyed how how much depth we were able to put into it. So
I just wanted to thank everyone for for joining, and I'll see you all
in the next one.