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.