Kate: Hello, PodRocket listeners. Today, we're bringing you a guest episode with Matt and Mike from HTML All The Things Podcast. HTML All The Things covers a variety of topics from the web development, web design, and small business worlds, discussing everything from JavaScript frameworks through how to handle coding interviews. They strive to explain topics in a way that all developers, junior and senior, can easily understand. They have new episodes every single week. So if you enjoy this episode, please consider subscribing to HTML All The Things on your favorite podcast app. Enjoy the episode. Speaker 1: When is the last time you listened to a podcast about web development, web design, and small business and didn't fall asleep? Yes, we cover web development, web design, and small business, but like actual human beings with personalities. If you're a beginner, we're not going to talk over your head. It's more like asking your buddy for help. We have guests. We have fun. And let me tell you, these two can get off on a tangent. Ladies and gentlemen, welcome to HTML All The Things podcast. This is Matt Lawrence and Mike Karan. Matt Lawrence: How's everybody? We are back in this episode 198. Full stack development has changed, war's changed, for any of you Metal Gear fans out there. But anyway, Mike's going to be talking about some Next.js, some Nuxt.js, some SvelteKit, and what's changed that way. I'm going to be talking about Top Gun: Maverick, because I can't stop talking about it, because it's freaking awesome. Go see it in IMAX before it disappears. Anyway, this is not a sponsor spot, I just really- Mike Karan: It's a sponsor spot. Matt Lawrence: I just really enjoy the movie. So yeah, go see Top Gun: Maverick in IMAX before you regret it. Anyway, if this sounds interesting to you and you want to support the show... wait, that sounded like a threat. Better do this before you regret it. Before you regret it leaving IMAX forever, there you go, that's not a threat anymore apparently. Anyway, if this sounds interesting to you and you want to support the show, you go check us out on that Patreon, leave a reviewer, writing on your podcast app, join us in our Discord server or share this with your friends. And now Mike, you have some news about full stack development. So please sir, take it away. Mike Karan: Yeah, absolutely. Matt, thanks. Honestly, full stack, it's weird because I've been a full stack developer for a long time. I'm more front end than full stack for sure but I have done a lot of backend work, I have done a lot of integrations into backends. I've built backends from scratch, so I've done a lot of it. But lately, kind of like today even or even yesterday, I woke up and I was like, "This is weird, full stack is completely different now." And I want to talk about that aspect because it seems to have happened kind of overnight. And it's obviously not the case, there's obviously a lot of steps that had to happen along the way. But what we have now is drastically different than what we had even like a year or two ago. And that's what I want to talk about. Mike Karan: And I wrote this episode in a way because Matt, correct me if I'm wrong, you don't have a ton of experience with serverless stuff, you don't have a ton of experience with JavaScript frameworks in general. And you have some experience with full stack development, I know you've spun up WordPress sites and stuff like that so you have some idea of the server management stuff especially, you know that stuff. But what I wrote this episode as is like an explanation to you about what's changed and how it's really different now, especially the serverless aspect. And so whenever I'm talking and you don't understand something, I think you're going to be a very good indication of the audience. So definitely just interrupt me or let me know and I'll try to clarify, because again, I have kind of you in mind while writing this episode. Matt Lawrence: Yeah. I'm definitely more, what would you say, I'm definitely more sysadmin and less backend developer, I guess you could say. Definitely, because I can build the server, even the hardware and I can rack it in the data center and hook it all up and then get it to work. But then you're like, "Oh this, this runs without a server," I'm like, I don't know how that works. I don't know how that works at all. So this will be interesting. Mike Karan: Yeah. And the big thing is I'm not that and I really hate sysadmin. And I think that's why I've been driven to serverless so much is as soon as I heard serverless, I'm like, "Oh my God, this is something that I want," because I like doing backend code, but I hate managing the actual server. And I'll talk about it in depth in a sec, but that's essentially serverless, that explanation that I just gave. Having backend work without managing a full server is serverless. Mike Karan: But first before that let's break down what full stack development actually is because I know some people out there kind of get confused about where the lines are. We've talked about this before on the podcast, but I just want to do a quick breakdown. So essentially full stack development is a combination of different technologies working together, primarily a development of a database where you would store your data, a server that interacts with your database in the way of writing and creating and managing and querying it, and the server also talks to your front end in ways of APIs or GraphQL or some sort of interface that allows the front end to effectively get the data and send the data that it needs to the database. So it's a little bit of an in-between between a database and a front end. That's what a server is. Mike Karan: And it's also a way for you to add some more complex logic that you don't want running on someone's computer every time. So if there's a mass amount of calculations or if there's transcoding a video that you need to do in the background, that's not stuff you want to do on someone's computer right away. That's something you might want to do in the backend and then store that stuff in a database and allow the front end to access, that content that's already been transcoded that has the heavy lifting already done on it, right? Mike Karan: So again, it's a combination of technologies that all work together, that really is full stack development. And the idea is a full stack developer should be able to create a application that uses all three of those technologies. It sounds simple ish when I say it, but in reality, it's actually very complicated because each one of those technologies is its own thing completely, a lot of the times requiring completely different hosting stuff, requiring completely different languages like programming languages, requiring completely different skill sets really. For instance, database querying stuff like MySQL and querying an SQL database is a whole other language separate from JavaScript or PHP or whatever else you would run on the back front end. Mike Karan: And a lot of the times when people go into full stack development, they kind of treat it as a side language and that turns into a very complicated relationship with your database querying. A lot of the times you're querying too much or you're querying too little, or you're not getting the right results back and you're just kind of doing a lot more processing than need be. So that's where it gets difficult for one person to be able to manage all of these different aspects of a potentially complex application. So that's the breakdown of full stack development. Mike Karan: What I want to do now is I want to break down what's changed from this perspective because we've gone from... I shouldn't say we've gone from it, but what's happened is there's this thing called serverless and it still allows for all those things that I said in full stack development, so data, database, server and front end, but it does it in a way that is much more approachable I would say from a front end developer's perspective. This is the lens that I'm wearing because that's who I am, I'm a more of a front end developer. So for a backend developer, this might not make sense and this might be something that's actually counterintuitive to them because a backend developer will most likely rely more on a monorepo type setup like Laravel or something that actually packages the front end into the back end. Whereas with serverless, it's like the back end is packaged into the front end. That's a kind of a distinction that I've realized as I was writing these show notes is that there is this paradigm in the back end where the front end templating systems are packaged, but the front end has never really had that. And now all of a sudden for front end developers, there's this tool that you can use with serverless functions, where you can actually write backend code without having to worry about an actual "backend". Mike Karan: So let's break down what a server actually means though, before we get into serverless. A server means that you need to manage some sort of installations of Linux or Windows or some sort of application that was running your server code, right? So you would have a dedicated server or a VPS that's running Linux or some version of a server software that can then run Apache and then can then run an installation of PHP or can run no-js or something like that. And then you have to kind of configure it so that all the ports work together so that it works with the firewall and et cetera, et cetera, like a lot of the stuff that you do, Matt, like the sysadmin stuff, you configure that box to be able to run whatever programming environment you needed to run, right? Matt Lawrence: Well, I have a good example actually for server. So this isn't actually directly related to websites, but it's a good example to kind of get a big picture view if you will, is that let's say you use Windows or Linux as a matter, and you set it up as a file sharing thing. So what you basically have is imagine this, imagine in a very simple form, not even in a data center in a very simple form, you'd have let's say a computer in your home that has a bunch of hard drives in it and those hard drives contain all your photos, family photos, and all that. And in order for you to look at them, you connect to this computer from your phones or from your tablets or from another computer and you connect to it here. Matt Lawrence: So what this computer becomes, this server rather, becomes is a file sharing server, a file sharing server, file sharing system, whatever you want to call it. So you would have say Windows server on there, or Linux server of some sort or Ubuntu server, whatever it is. And you would then program it to do something. So you wouldn't program it in the traditional sense like literally coding it up, you would use something like I use Samba Share a lot on Linux. I'll use Samba Share on here, on that computer. So I'd install, let's say, Ubuntu server, I'd install an application called Samba, I'd go in and mount all the stuff, so I'd say mount all the drives and then I in Samba Share would divide it up into, let's say, oh, if you're looking for 2022, if you're looking for 2023, if you're looking for 2019, whatever it is, these are the different years of the photos that you can go. Matt Lawrence: And then you would then program it such that your router would allow the traffic to it. You allow the computer and its own personal firewall, or the server to allow traffic in, you have different security systems like username and password to access certain shares. So let's say you want your kids to be able to access 2022, but you don't want them to access 2023 because there was like a surprise party that you have planned or something and you don't want them to know about that. So the 2023 is now blocked off to them and those type of things. Matt Lawrence: And that's what this server does. This server has all these hard drives in it, has, in this case, Ubuntu server, has Samba running on top of it, which is an application that's for file sharing has that configured. And then you also have to configure your network such that people can connect to it. This is usually the example I use for its most basic form. Because people get all tied up in, "Do I use Linux? Do I use Windows? Do I use this? Do I use that?" It's like, no, you're just basically configuring an app or multiple usually to allow it to be accessible or usable in some way. In this case, we just want to mount different hard drives on my Windows PC, not on Ubuntu server, I would go in and mount a network drive and use all the credentials and pathing that Samba Share provides, that is provided by the server. And now I have a little mounted hard drive or network drive that says 2-22 and I click in there and all my photos are there and you can do that with various phones as well. Android is one of them I know you can do that, and that type of thing. Matt Lawrence: So that's just a really basic example of what let's say a traditional server is. And obviously different apps like Mike has said is something like Apache or MySQL or whatever those things. And they need to have certain things configured to allow the proper traffic to be able to flow literally into the server and out of the server as well. Mike Karan: Correct. And it gets progressively more complicated and less complicated as well depending on what you need. A lot of services will kind of help you manage some of the connections between those things, some servers won't, et cetera, et cetera. But at the end of the day, you're managing a box with a bunch of applications on it and you're trying to get those applications to talk to each other as well as talk to the outside world a lot of the time. That's a lot of what web servers really need to do, right? Mike Karan: The management of that is what always didn't scare me, but it always put me off because I have so much to learn on the front end side, I have so much logic that I need to apply. And now I have to learn like sysadmin stuff on the back end, making sure that ports are open, making sure that these apps that are talking to each other properly and writing the backend code on top of that. Writing the code was just one very small part of the actual backend process for me personally. Mike Karan: This is where it's kind of a little bit different or actually significantly different with serverless because with serverless means you don't have to manage any of that. You don't have to do any of the actual server stuff where you have to manage what Linux installation and stuff it's on. All you do is you're writing no-js code. Now there is I think PHP serverless and stuff like that. But in this specific example and the stuff that I'm going to be talking about with Next.js, Next install kit, I'm going to be talking about no-js and that's JavaScript related backend service. Mike Karan: So that's where it kind of clicked in my mind where I'm like, "okay, so I can write paths. I can create routes. I can interact with a database," that's a really big one, "All inside of my JavaScript code without having to spin up a whole other server." That's the power. It usually supports all the express framework routing methods and all of nodes or let's just say most of nodes, like most of the packages that node supports, it will support like file based APIs and stuff like that. So you can do anything that a regular server could do to a limit inside of your regular JavaScript project. And at the end of the day, the actual management of that server and the hosting and the communication between your front and the back end is all handled by a third party. Mike Karan: Now to some people out there, I'm sure that there's a bunch of developers listening, that sounds like a nightmare because you're thinking, "Oh, I can't manage the traffic throughput, the security aspects and stuff like that." There's a lot of specific cases where this might not work and I'm not saying this is a solution that's going to work for exactly every single project. A massive project with a billion connections going to it that need a lot of processing on the back end side, this might not work for, right? This is not a one solution that replaces backend development or backend server, regular servers. This is a solution that I think will work for most projects though. Mike Karan: If your site, for instance, needs a job board and they need a more advanced functionality where your employees can add jobs or your HR department can add jobs and people can apply to those jobs, so it's kind of like a little web app inside of your company's website. This is a perfect solution for that because it doesn't need a ton of processing in the back end, it just needs a few routes for contacting a database, for editing that database, for querying that database, it just needs some routes, maybe some authentication on top of that, any sort of OAuth situation, right? And you want to set up a off situation where you can log in with Google, you can log in with Spotify or whatever. All that can be handled inside of a serverless function without having to spin up a whole other dedicated server, just to handle some authentication. That's the power of it in my eyes. Mike Karan: A lot of the times when I had to set up authentication for, I remember I was building a hat website a while back from scratch with no-js, you know what took me the longest? Setting up the no-js server, not writing the no-js code, the longest was literally setting up the server so it could run on Digital Ocean so I can contact it so it's secure and all that. All of that is handled for you in a serverless environment. And that's where the appeal is to me for small stuff, for stuff that is quick, that you need done quickly, right? For stuff that is a response request. A lot of those things are key attributes into picking a serverless infrastructure. Mike Karan: And a lot of the times with that decision between server and serverless, there obviously are some downsides to serverless. I'm not saying again, serverless, isn't the golden tip solution for everything. Some of the downsides can include the amount of requests you can make in certain, I'm going to use Vercel as a industry standard right now, but there are different services that offer serverless functions. I know CloudFlare offers them, I know Netlify offers them now. I think GitHub even offers them, GitHub pages, but I'm not a hundred percent sure on that. Mike Karan: Regardless with Vercel, in the free tier, your server function as limitation, your serverless function can run for only like 10 seconds. So if you have something that runs for over 10 seconds in terms of you request something, the server function needs to process something that takes 10 seconds, it'll time out after that. Now, you can increase that by paying for the pro plan to a hundred seconds or something. Again, this is where I kind of say that like, "Hey, if you need to do some very server intensive work, serverless functions are probably not going to work for you because of these little limitations." Mike Karan: But thinking back, what function have I ever created that needs to run for over 10 seconds? I personally can't think of one. Maybe there's something, again, a lot of stuff that's done in the background could be a problem. Because if you have, again, transcoding video is not something you would do in a serverless function, because that could take more than 10 seconds, right? Anything that you kick off that could take like a minute, two minutes, 10 minutes, all of a sudden then you're thinking, "Okay, I need to build a server." Mike Karan: But back to my idea with the job board, with the authentication, all of that is instantaneous. If you have so many jobs in there that is taking 10 seconds for you to query the jobs or to write a job, then you have other problems outside of your serverless function, your company is going down because you're hiring so much. I don't know. I don't know what's happening there. But regardless, it's not going to be a problem. And a lot of applications out there, a lot of people that are building applications are in that category of quick query, do some edit operations, do some complex data analysis queries. All those will take you not that much time and can definitely be done in a serverless function. Matt Lawrence: I have some questions. I'm a little confused. Mike Karan: Yeah. Do it. Matt Lawrence: I might be pretty confused actually. So what does this look like from the hardware end? So I'll give you an example. So you have a server rack and you have one server in there, that server's running, whatever, let's just use a Ubuntu server, there's a bunch of other ones you can use. Let's say Ubuntu server. That a Ubuntu server can run a collection of applications. It could run Samba, like I said before, it could also run a number of things. It could run even your authentication, it could run whatever applications you need. Now, obviously there's reasons for you to have more than one physical server in the rack, redundancy, maybe there's some security stuff you don't want to be crossed, this and that. But one server, depending on its power and depending on what's required of it, one physical piece of hardware is able to do a bunch of different things, much like our computers are doing right now. Matt Lawrence: I got Discord open, Messages for Web or whatever the heck it's called now, Microsoft To Do, I'm talking to you on here. I got Audacity, it's recording. This microphone is talking to it. There's a number of things. So these servers can do similar things. Again, I realize there's reasons why we have multiple servers in some ways like one server might be just for databases, one for organization, for security, for power distribution, or literally computing power distribution among other things, redundancy and stuff. Matt Lawrence: Now, what I don't really understand is you're saying this is serverless, but it's still running on a server. Now this might be a dumb question though, but it sounds like you're doing a real quick something so you said like under 10 seconds, so you're doing a real quick, whatever it is. And then it's like shutting off, but is it shutting off a VM? A VM meaning a virtual machine. I mean, I don't see it from, let's say, bottom up in which the bottom I mean the hardware. What's going on here? Because it's called serverless, but it sounds like serverless is more a marketing term than literally, it's not like the server literally disappeared and the website user or the client, like the authentication stuff is not being done on their end. It's not like we're blockchaining this in which we're distributing the computing or something. This is like, there's still a server somewhere. Matt Lawrence: So I'm just not fully grasping, is this effectively what's commonly called a managed VPS, or even a managed dedicated server where it's just, there's a company offering the sysadmin services, or I feel like I'm missing the point. Mike Karan: So okay, so first of all, really good question, and this is exactly why I wanted you to listen and ask these questions, because I think you're not the only one that's going to be asking this. And in fact, I was the exact same way in terms of skepticism towards serverless because at the end of the day, you're a hundred percent right, serverless doesn't mean no server. All serverless really means is that you don't manage or spin up or touch the server infrastructure. You have some way of configuring stuff a little bit, but at the start of it, you don't have to touch anything to get your server "functions" up and running because they're hosted, they're managed and they are actually started and stopped all throughout the software of Vercel or whatever other platform that's offering this. Mike Karan: Calling it a managed server is a little bit incorrect because a managed server usually is just like the company going in there, setting up a server for you, and then allowing you to contact them to add stuff and disable stuff. This is more of a server as a service where it's doing all of the actual management stuff for you in the background, you don't have to touch it, you don't have to worry about it. That's the serverless aspect. The serverless aspect is the configuration aspect. Not the fact that there's no server, but there's no server configuration required or server worrying. Matt Lawrence: Basically it'd be like, I'll give you an example, so we've recently had to use a VPS for a project and we had to on this VPS, it's a smaller project so we have a database, a web server, which I believe was Apache, so Apache let's say MySQL, and I think it was running with cPanel, so cPanel which allows you to manage a bunch of other stuff as well. There's DNS and stuff in there, but let's just keep it simple, Apache, cPanel to control it and then the database, which is MySQL, that's all done on one box. Now I understand it's a virtual private server so it's a VM in a blah, blah, blah, it's a whole thing, we're not going to get into that. But the whole thing is it's like, that's effectively our server stack, if you will. Matt Lawrence: So you're saying that instead of that Apache and that MySQL running and being ready all the time, you would have a really quick function that goes out and say like, yep, "Hey, I need to check a list of the users," and then it just quickly shoots out. And instead of it sitting there all the time ready, and we haven't configured it. So for example, in this particular case, I had to choose the database quotas and the database name and the database user, and what access that user had for security purpose. And then I had to import the data and I set up a backup system and then set up a remote backup system. And so I literally had to go in and configure all this. Matt Lawrence: And then I was doing most of this from cPanel and we work with a backend developer and he was going in and using more of the command line stuff because I'm rusty at it now. So he was using more of the command line stuff going in there trimming some stuff that the cPanel, which is the user interface we use to control the server, the stuff that the cPanel just couldn't quite get. So instead of us doing all that configuration, this and that, it sounds like what you're kind of doing is you're kind of going to Vercel, which is a hosting provider if I remember correctly you mentioning, so you'd go to Vercel and you would literally just say, "I need a MySQL server with the name Matt," let's say, it's my portfolio site with the name, Matt and I need an entry called Matt, an entry called projects and an entry called contact. You know what I mean. Mike Karan: So the MySQL side of things is actually a little bit different. Like what, what you would go to Vercel is here's a JavaScript file that has a route for accessing a database or accessing something, like a server function in it that you need to run on the server, right? Here's just a JavaScript file. Can you please run it whenever I hit this endpoint? And it's obviously easier than that, you don't have to actually have to declare it like that to Vercel you actually just put it in the file structure of your application. And I'll explain that in a second. But you're just uploading a JavaScript file or a TypeScript file. And if you put it in the right route inside of your folder structure, when you hit that route in your domain, it will kickstart that serverless function, run it, do everything, send back the stuff that you need and then shut off. Matt Lawrence: Okay. So describe the right route. So give me an example. So would it be something like the login route? So it's like- Mike Karan: Exactly. Matt Lawrence: I'm at the login page and I've typed in my username, I've typed in my password and I've pressed login. Now your front end code needs to be in the right route as in the slash login logging in or whatever, and it needs to go. And so a function is very briefly spinning up and oversimplification, but it's basically just checking if my username and my password is correct. And then that route, or that function shuts down. And so is that what Vercel is providing is? You are effectively saying, "Check the username and password, check the login data," and Vercel, they're checking login data and it just quickly does it. Is that effectively what's happening here? Mike Karan: So you're writing the code to check the login data yourself. The Vercel is just hosting that code inside of a serverless function, allowing you to access it through a route. So the routing comes from the frameworks and I'm going to talk about that literally as the next segment. The routing comes from the frameworks and Vercel just allows you to take that route and spin up a function, do whatever you say in that function. So that function could be, like you said, checking a database for the right key, for the right password and then responding with a true or false or responding with the authenticated response, whatever it is. And then it would shut down. Mike Karan: Now the starting and shutting down part is a little bit more complicated than that where there is such thing as it's being, I can't remember what it's called, but essentially it's not fully shut down most of the time. So when someone hits it actually puts it in a spot where it's cached to a certain degree where if the next person hits it's going to be even faster. And as long as someone's hitting, it's going to be really, really fast. As soon as the 10 minutes goes by, or however long goes by, it's going to spin down a little bit, but it's still going to be like the first hit is still going to be fast enough to not notice. That part is really complicated, but that's all done in the back end, right? That's all done behind the scenes, I should say, by Vercel. Matt Lawrence: So like you said, you're writing the authentication code. Let's say you're a front end, strictly front end developer, do you still need a back end developer to write the authentication code in this instance, you still need that? Mike Karan: Yes. Matt Lawrence: So the only thing that you're losing is the server admin part. Mike Karan: Yes, that's correct. You need to still be able to write backend code because that's not going to be written for you. You still need to be able to interact with a database from the back end. Now there's a lot of tools that can help you there, but they can help you in the back end as well. So you still need to be a full stack developer it doesn't take that away. All it does is removes the server management aspect from it. That's it. Matt Lawrence: Just the hardware though? Mike Karan: Yeah, just the hardware on the software side of things. You don't have to manage any of the server stuff at all, you just have to write server code. Matt Lawrence: So you're never given, like, let's say you spin up an instance in any of the number of cloud services out there, you're never given just like a blank hard drive. Oftentimes these services will ask if you want a certain OS installed or whatever for ease, for example. But let's say that doesn't happen. You're never just given, like, "You've remote access to this piece of hardware and enjoy," type of thing. You're never at the blank level, if you will, you're on Ubuntu with the database server installer or what have you, you're already... Mike Karan: You have a no-js environment, that's the best way to describe it. You have no-js running essentially, and you can access it through a route by just putting a TypeScript or JavaScript file inside of a folder specifically in your framework. Mike Karan: So let me quickly talk about the framework side of things and that might put stuff together for you because that's where this kind of takes off, right? That's the whole point of this is so that you can use frameworks like Next.Next and SvelteKit, which are actually frameworks that are built on top of popular front end JavaScript frameworks, like React, Vue and Svelte respectively and use those frameworks to build a full stack application with this serverless function code in mind. So those frameworks, like Next.Next and SvelteKit. Mike Karan: What they provide really, and the biggest part of it is page routing. So the ability to have a pages folder inside of your folder structure and put, for instance, a home.svelte or a about.svelte in there. And when you launch the application, the dev server or the production build and you go to slash/home or just / for home and /about for about, it'll actually take you to the right page without you having to write any logic there, right? A lot of the times, if you just use the framework, you would either have to bring in a third party router or bring in routing and have to set up your routes manually, like actually in code. Mike Karan: What these frameworks like this SvelteKit and Next.Next do is they allow you to not have to do that. And it might seem like not a lot, but when you start thinking about query parameters, when you start thinking about API routes that we're just going to get into at the serverless functions, when we start thinking about server side rendering and static site generation, all that really is embedded into routing. And that's why it becomes so complicated and that's why a framework like Next is so necessary when you're building a regular webpage inside of React. It's so much easier to build it inside of Next because it assumes so many more things for you rather than you having to handle it one by one, case by case basis. Mike Karan: So where it really excels again, is ha being able to have an API folder in your routes, right? And inside that API folder in your routes folder, you can put something like off.js. And using the express framework, which again is no-js, you can just write a basic backend authentication code in there that would typically run on a managed server or a dedicated server, but you're just writing it right inside of your front end frameworks' code base and it's going to automatically create that route for you. So example, once you deploy the application to Vercel and you, inside of your application, navigate to /API/off, it'll automatically hit that backend code that you wrote and do whatever it says and respond with whatever you need without you having to, again, spin up that server that you would usually have to do that can run Node, that can run Apache, that can run whatever you would need to then only do that route. Mike Karan: So from a UX perspective, this is a crazy step because again, the huge step of setting up a whole managed service to run your routes. Does that simplify it in any way for you, Matt? Again, it's built into these frameworks that you can just write the API routes right inside your code base. Without having to go to a different code base, without having to spin up another server, it's all inside your code base. And when you deploy it on Vercel, it automatically knows that since this is an API route, it will deploy it as a serverless function. So you don't have to set that up even. Matt Lawrence: Why are you spinning up another server for an API call? Mike Karan: What do you mean? Matt Lawrence: You're saying for each of these functions, like API call, I think you mentioned a couple others, you're saying that you need to spin up another server. Why are you spinning up a server for each? Mike Karan: Well, you would spin up one server for all of them obviously. If you had the need for any sort of authentication inside your application, you would spin up Laravel or PHP or whatever in the background, you would spin up a whole server and you would put all your routes in there. Matt Lawrence: So is Vercel effectively dictating... I know we're talking a lot about Vercel, but as the host, is Vercel dictating what it has on deck, like we have PHP on deck, we have Node, we have this, we have that? Whatever it is they have, we have all this on deck, go ahead and use your framework of they have a collection that they work with and you go in and you do effectively your backend work in a file, like you normally would like in PHP, on WordPress, let's say, and then they handle the processing of that. But obviously there's going to be, as you compile with these frameworks, you're going to throw it into some files or whatever so that they can wrap it and they understand that it's a serverless function. I don't see the point in this actually just to be totally honest with you. The thing I don't understand, it's like, we still need a full stack dev, there's still a server. Mike Karan: But you don't need to manage the server, Matt Lawrence: But don't you though? Mike Karan: No. Matt Lawrence: With you doing the back end code, are you saying you don't need to manage the server as in, you don't need to update the PHP version, you don't need to update the version of cPanel available? Mike Karan: You don't need to have a cPanel and you don't need to worry about any of that period. There's no process- Matt Lawrence: So how are you...? Go ahead, sorry. Mike Karan: There's no process in terms like when you essentially connect your GitHub repo to Vercel, there's no process where you're like, "Oh, I'm going to pick this version. I'm going to use this tunnel. I'm going to use this port." There's no process that you have to do that. It just takes your configuration from your GitHub, automatically configures everything for you and deploys the front end with the serverless functions for you. It automatically does that straight from your GitHub. And anytime you do an update to your API routes or your front end, it'll automatically rebuild it and deploy it for you without you touching it. Matt Lawrence: I guess my hesitation here, or my question really is there's a reason why we have server... I mean, the server's available, or let's say more traditional hosting with a server is that there are times in which you need a little tweak, a little hack here and there to get something to work. And it doesn't sound like you would have the option to do that anywhere other than the front end, because it sounds like you're kind of limited in what you do... Maybe that's wrong. It kind of sounds like you're limited in what you're doing in your backend code, you have to do something that's explicitly compatible with what a hosting provider like Vercel is offering. Mike Karan: Yes. Matt Lawrence: Whereas let's say you can run PHP, these are the wrong versions, but for example it's like you're using PHP 2.0, which is very old, but using PHP 2.0 for everything. But you have this really, really old application that requires PHP one. I mean, if Vercel in this example kills PHP one entirely, you're at the mercy of it. But if you have rented a server via whatever, like a VPs dedicated, or even shared to some extent, usually not shared, but you could go and you, the system man or the DevOps or whomever could go and install PHP one, or keep it installed as the case varies. And then you could use PHP one and two. Are we being sort of pigeonholed here by you doing this? Mike Karan: Yes, no, you're a hundred percent being pigeonholed to a certain degree. You have to stay within the limitations of the service. But what I'm saying is, and like I said this a little bit before is I would say 90% of applications out there don't need what you're describing. They don't need PHP one and control between PHP one and two. And usually when you're working inside of those kinds of applications, it's a nightmare anyway. And you need to manage multiple different servers, you need to manage access between the servers, you need to manage crazy amounts of security, right? Security is a whole other aspect, when you're managing PHP one security goes out the window. Mike Karan: So the idea of Vercel and the idea of the serverless stuff is that it will handle most applications out there, like a job board, there's no complexity there, you don't have to jump the route there. It can easily be done with regular serverless functions. You're just querying data, you're sending back data. You're not using anything complex back and forth, like your UI is all handled by your front end framework. So anything that you do on the back end is going to be a very simple call there through and back. So you don't need to spin up a whole separate backend server to have to manage that and also manage that backend server and pay for it where it can all be done straight on Vercel without you having to touch it at all. Mike Karan: And continuous integration is fully built in, right? So anytime you update your Git repository or whatever branch you pick as your continuous integration branch, it'll automatically update your code in the production site and set up a staging environment and all that. The power of this isn't that, "Hey, your outlier can work because we're going to give you full access to the back end and will let you download PHP," there's already services that can do that. If you need that, that's fine. You know what I mean? That sucks, but that's what you got to do. The power of this is like, hey, this is a fully managed service that allows you to build full stack applications really, really quickly, and also robustly, securely and scalable. The big thing here, the big asterisks, not asterisks, but star would be the scalable part too is that think about setting up a server function that needs to handle millions and millions of requests. Well, you got to build full scaling redundancy, load balancing, all that into it. All of that is built into serverless. Matt Lawrence: I can definitely see the benefit there, especially because we haven't personally worked on projects that have required that because obviously even one, let's say, even half decent or even older server, depending on the complexity of the site and how well it's been optimized, I mean, realistically can serve hundreds of people a day and even hundreds of people at the same time, depending on how good the network is and this and that, there's a number of factors. But once you've overwhelmed your options between VPs and shared and dedicated, once you've overwhelmed that, I mean, absolutely as we all know, cloud computing is the scalable king, I guess you could say. And so this sounds more like a cloud computing thing. Matt Lawrence: I'm starting to get it. It makes a lot more sense when it's in that context, when it's not just one random shared hosting plan that you just purchased at random. And I'm going to run through an example and correct me as I go with say WordPress. And I understand that WordPress is different, but hypothetically. So a general thing that we've received as a web dev agency is somebody has an old WordPress site, they want to move over to a new host. Mike Karan: So actually, before you fully jump into WordPress, I kind of want to clarify something here too. WordPress is the perfect example of what I was saying that is the backend version of this, right? So the backend version of a "serverless function" is WordPress because it handles almost everything for you, right? Yeah, you still have to manage some, there's some server hosting providers that manage your full WordPress as well. So WordPress is a good example of like, "Hey, I'm a back end dev so that's where I'm more comfortable because everything's done in the back end is just templating in the front end, I don't have to worry about the front end logic code and stuff like that, I can do that all on the back end." So that's where WordPress was, right? Mike Karan: So it's a perfect example of the parallel between the back end and the front end, because the front end all of a sudden has that same capability, right? Where a front end dev that's more comfortable on the front end is now only working in the front end. Yes, he still has to do some back end code, but it's the same thing as asking a back end dev to do a little bit of front end code, because it's not a lot and you can learn it and it's usually in the same language that you're coding in JavaScript in terms of no-js. So that's where the parallels kind of go where WordPress isn't serverless obviously, but it has the kind of similar functionality in terms of managing your setup process and managing your connections between your back end, front end and in between where this is now providing custom code people that do a lot of custom applications, like with Next. Next and SvelteKit to have that same kind of ease of use developer experience on the front end. Matt Lawrence: Right, WordPress is managing your plugin installs, realistically it can even do its own updates, albeit half the time it breaks. But anyway, depending on how many plugins you have, of course. But you can install full light box functionality, let's say, to your site, depending on if there's a plug-in available, even if you're not a developer at all. I mean, I don't recommend that, but stuff like that, it manages all this. Matt Lawrence: Okay, so an example would be in my head and correct this if it's wrong, was like WordPress still. But one thing that we'll commonly receive is a package from say another dev or another host and it will have a copy of what was in the public folder, which is the WordPress installation, right? It has the WordPress content stuff in there, it has the index files and a bunch of other stuff like that. It has a bunch of stuff. And then we'll also receive a copy of the database, a back up of the database. So generally what I'll do is I'll go into some sort of shared plan, because it's not usually not too high traffic, I'll make a new database, I will make a new database user, I will take that database user, give them permission for the new database. I will go and I will import the backup that I received in the original package into the database. Now my database is ready. Matt Lawrence: Then I take the contents of the WordPress site, so basically let's say the front end stuff, although it does have PHP scripts and stuff like that in there and I take the WordPress installation, right? I take the WordPress installation, including all the content that was uploaded and stuff like the images and whatnot that the user has uploaded. I take that, and again, this is all generally, and I throw it into the public_HTML folder, because usually we're on Apache or something similar and then I go into the WordPress config file and I configure the connection to the database. And then I also, if they're changing URL, I have to go into the database and change a couple of things to fix that. And then nine out of 10 times the permalinks don't work and I have to go and save that. Matt Lawrence: Okay, so in a serverless situation, I understand you're going to talk about databases in a bit, but in a serverless situation I'm not installing the WordPress, the WordPress is being worked on like we're... How would you say this? It's like, we're doing all of our custom WordPress stuff, say our plugins, this and that in some sort of framework and then we're just calling on WordPress functions that Vercel would execute. And then it hits a database which is probably not installed by me fully or whatever, you're going to get into databases in a bit, but I'm skipping all of the file upload, extract, delete the remnants, place the files where they're supposed to be, go here, go there. In this hypothetical framework that I'm working in, I'm literally calling on almost, I guess I would call them, remote WordPress functions. If I was working on like Vercel WordPress, if it was a service they offered, Vercel-WordPress, I would literally just call WordPress functions. Matt Lawrence: I'm not worried about literally installing the WordPress content and all the other WordPress stuff that comes with it. I'm not installing all those folders. I'm not doing any of that. I'm not going in and changing that specific file necessarily, I'm configuring a file in my code to connect to that database. I'm not going in and messing with the cPanel or anything like that or going into CMD to import the database if I need to or stuff on or FTPing, I'm not doing any of that. I'm connecting to in this hypothetical, the Vercel WordPress situation and then I am writing all my code that I would need, although you don't really need much, so maybe WordPress is the greatest example. But in general, I'm not dealing with the WordPress install. I'm worried about the content and I'm worried about anything. I need to change in my little front end thing and then it runs WordPress for me whenever it needs to be invoked. Mike Karan: Yeah. I think that's a good example. Initially I was having trouble picturing it, but then once you've brought in the fact that, Hey, it's just WordPress, the actual installation stuff is done in the background, that's exactly it. You don't have to worry about setting up the server infrastructure for WordPress, you're just worried about writing code for WordPress. Matt Lawrence: Yeah, if I was writing my own little custom plugin or something, which you don't normally do too much, obviously because you use existing plug interest is why I thought the example was a little shaky, but just in general, it's like, I'm not doing that whole situation... Again, I know you'll explain databases later. But I'm not doing that whole situation where I'm moving the files in and checking the config and then making sure there's a database user and all this stuff, I'm not doing all that. And then also it doesn't end there, half the time it won't boot up, you got to go in there and change the HD access, which is a big server thing and you have to go change the HD access and make sure that's correct or make WordPress regenerate it or this and that, and this other thing, change the PHPI&I or whatever the people say so that you can change how big your uploads are and stuff like this because often time it's very limited and you want to have bigger images and yada yada, yada, the list goes on. So I'm not doing the server stuff, I'm doing just the WordPress stuff, if that makes sense. Mike Karan: Yeah. I think that's a good analogy. This actually sounds like a product that could be made, what you're describing in terms of use case because I think a lot of the issues that people have is the server stuff. But like I said, there are managed hosting platforms for WordPress that almost do exactly what you're saying, right? Matt Lawrence: Yes, like Bluehost I think is one of them and there's a lot of one click installers, even for, let's say "generic hosting" where I can one click install WordPress and stuff like that. Of course, because WordPress is so popular there's tons of stuff that's been built around it to make it like an easy to use thing for someone that doesn't code at all, even. It's been adjusted to different levels of difficulty. But in our case if we're just receiving, let's say, this raw package from the previous host and we're putting it in a new host, that's how we handle it. And so I wouldn't have to handle say 50% of that it sounds like. Mike Karan: Yeah. And that's the kind of mentality that I use for this too, because this is the same kind of ease of use thing but for front end developers. Because again, a front end developer doesn't necessarily, or a full stack developer even doesn't necessarily need to know all the sysadmin stuff to be an effective developer. They need to know how to write front end and backend code, which again, a lot of the time can be in the same exact language. So if you're a front end developer with a good understanding of JavaScript, you can write Java like no-js backend code. It is interchangeable in the sense that you just go and look at the docs and you figure it out. Mike Karan: The part that takes a lot more different mindset is the sysadmin stuff, is the load balancing stuff, is the caching, all this stuff that is so different from writing code, that it shouldn't be done by the same person in my opinion, the same person that handles your server infrastructure and your scaling and all that should be different from the person that actually writes your code. Not that they don't cross between each other, they should understand both sides, but in a production environment really they should be different. So for a startup or for a small dev shop or for a developer that's starting out taking on that whole aspect themselves, and a lot of people did that, I did that, you did that, we all had to put on that hat many times. For me, again, this serverless concept with Next.Next and SvelteKit has changed the game in terms of full stack development. Because now I can focus on the code. Mike Karan: For example, I was working on the Solarians project and we needed a backend set up to see who minted what NFT or whatever, it doesn't really matter, right? It's a small little backend. It's not very complicated, it just needed to essentially be able to add a user, it needed to be able to query for the right parameters to be able to check on load and stuff like that. It wasn't complicated, but it needed a database, it needed a backend. It needed something that was persistent and not front end. I just spun up an API and I spun up a little database, and I'll talk about that in a second. But all of that was done without me having to spin up another server, which is something that I would've 100% had to do two years, three years ago. I would've had to spin up another server most likely and run the routes for my code and maybe use Firebase for the database or something like that, right? So I don't have to add a database on top of it, Mike Karan: But all of that is something I would've had to do. Whereas with now, I literally had to write JavaScript code and Vercel handled all the backend stuff for me. I didn't have to do any of the server infrastructure. So it saved me in my approximation at least two or three days of work. Because again, I can spin something up pretty quickly in the back end to just work sort of, especially locally on my machine to do testing. When it comes to production, that's a whole other story. Just put SSL on the table, bring SSL into the picture, having a VPS with SSL and all that, a day of work for me. Because I don't know what to do, I was constantly battling with it. I don't know if you remember Matt, when we were creating No BS News for Reddit. I spent 12 hours of the, I don't know, 16 hours that we spent that day bashing our heads against walls working on SSL. Matt Lawrence: Yeah, I remember that. I do remember that. Yeah, you couldn't get it to, I think, issue you a cert or issue you one that worked I think. Mike Karan: So today that project would probably take me two hours. That's the difference. Honestly, I can't evangelize it enough in terms of time saving, that's it. In terms of functionality, you lose some, some robustness. Matt Lawrence: I was going to say, how are these going to age too. Mike Karan: You lose some customization, you lose some customization. I mean, Vercel is a big enough company that I'm not too worried about it crashing or anything like that, they're the creators of Next.js in fact, they just bought Svelte. They didn't buy SvelteKit, I should say, it's all open source with Next.js, but they just hired the creator of SvelteKit to work on SvelteKit full time and work with them to make sure that the integration between versatile and SvelteKit is good. They're very dedicated to this craft and they also have a decent business going. So I'm not too worried about them crashing or anything like that. Matt Lawrence: Well, I'm more so asking about, so obviously they're relatively new and I'm not talking to their business, I'm talking about serverless in general as a concept. I'll use WordPress again, something like WordPress, there's WordPress sites that are left at a very old version. And whereas that's not recommended for security reasons, it does happen even with the most responsible of administrators when there's a very specific plugin that somebody absolutely needs and it's absolutely incompatible with the latest WordPress version or a plugin that they absolutely require just causes a weird conflict with another plugin but only when they're both at certain versions. And so older versions get left. Matt Lawrence: Absolutely, that happens to tons of websites. And I understand we're not talking about WordPress in general, but if you were to force WordPress along, if you were to force it to update, force it to upgrade, force all these things, you'd start seeing 500 like Google AR500s you'd start seeing 404s, you'd see sites go down, you'd see CSS disappearing, you'd see everything but the homepage working, everything not working except the homepage, you'd start seeing sort of the classic WordPress problems. Matt Lawrence: How is serverless with a site that's not going to be maintained even? I just talked about responsible people trying to update as much as they possibly can, but being left behind due to technical problems, what happens when somebody starts a WordPress site because they're trying to start a business that's unrelated to WebDev, it's more about the blog? And they never update or manage their WordPress or in this case they never manage their serverless application. How is the ma how is an app/a website with lack of maintenance going to age on something like serverless? Mike Karan: I think very predictably, like you're saying, once a server is updated, there's going to be deprecated stuff and there's always the potential that one of the functions that you're using could be deprecated, right? You'll have warnings about that for years and years and years before it's actually going to break but there's a very real possibility that since you don't control the environment fully that five years down the line, six years down the line, you could have issues. Absolutely, if you're using something- Matt Lawrence: An enterprise would probably struggle with serverless because they would be pushed along potentially too quickly. We've seen people argue for the continued use, even as soon as a few years ago, of Windows XP, because they just do not change the cogs in their machine for whatever reason. Mike Karan: I agree. I agree with you there, that enterprises would have an issue with this. But my argument stops with the fact that shouldn't be the case. I know it is the case, but the fact that enterprises are using Windows XP is actually a disaster for security and for longevity and for developer hiring, right? So if I was in a position at one of those companies and I had any sort of power... What the Hell? Matt Lawrence: Is somebody beating on your door, is somebody breaking in over there? Mike Karan: Yeah, give me a second. Matt Lawrence: As exciting as a podcast can get, Mike is just about to have his door knocked down by a random telemarketer or something trying to sell him something like, "Hey man, I heard you were talking about Vercel. Well, you can come check out our Vercel alternative," or something like that. Mike Karan: That was strange. I don't know. Matt Lawrence: What happened? Mike Karan: I don't know. Matt Lawrence: Was somebody just beating on the door and then that was it? Mike Karan: No, it was like a vent or something. Someone was hitting a vent. I don't know. That was really weird. Matt Lawrence: Maybe they were just like putting something into their place and then bumping into it type of thing because they're trying to get into a door. Mike Karan: I guess so, yeah. It was just a really weird sound. Okay. Matt Lawrence: I mentioned in the show here that this is as exciting as the show gets because a Vercel alternative salesman's knocking on your door, "Hey, I thought you heard, you were talking about Vercel." So enjoy that. Enjoy that hypothetical that didn't happen. Mike Karan: I agree that it could be a problem and it should be a problem. It'll probably be a problem for a longevity. If you just leave an application for five years, especially if it's complex, there's a chance that it'll break. Whereas with maybe a dedicated server, especially if you're the one that's hosting that server, there's probably less of a chance it'll break. But on the other hand, browsers sometimes will change and deprecate. So you do have to keep up. In my opinion, leaving something for five years and generating an income or relying on it to be a part of your daily workflow is a dumb idea at the end of the day. Matt Lawrence: You're better off going to the cloud for stuff where it's like, how WordPress, for example, you could do self-hosted or you could go with a managed self-hosted solution, I suppose, what it is, or you could go to wordpress.com and let them do it. It's sort of like if you don't want to do the maintenance, you kind of have to these days, so you should kind of go with one of those services. Mike Karan: Yes. But then you bring that same issue that you were talking about where a plugin could stop working because those guys updated your WordPress and all of a sudden they didn't realize that plugin wasn't working. So it's a give and take situation. It's idealistic to think that people are going to do this, people are going to always every year go back and update their applications. It's not going to happen, they're probably going to wait for them to break and then panic and then update them. That's just the status quo and I don't think it's going to change anytime soon. Mike Karan: But ideally if you're in a position as a developer to put in systems for yearly checks of deprecated functions in your applications is probably a good idea across the board. Because again, if a deprecated function is removed from Node, sometimes those functions can be removed from the browser too. So you could have a situation where Chrome doesn't support your application anymore, that does happen, you know what I mean? Because they've deprecated something. So you have to go in there and update it and there's nothing you can do against that. No amount of dedicated hardware is going to stop that from happening because Chrome is not under your control. So I don't know. Mike Karan: You bring up a solid and a valid issue. I just think that it's definitely something that could be easily monitored as you're growing. And when you get to the point where you're so big that your application may outgrows serverless, which is possible, even though I have seen applications with a billion hits with serverless and it still worked, I think there are certain situations, like I mentioned, data processing and video processing, if you outgrow that, then transitioning it to that infrastructure it won't be that hard because serverless doesn't mean that you're writing completely different code, it just means that you're writing code and not managing the server. If you need to convert it to a server, you'll just convert it to a server. You'll just take the code that you've already written, put it in a file and spin up a server. It's not that big a deal. Matt Lawrence: All right, fair enough. Mike Karan: Okay, before we wrap up, I do want to hit databases really quick, because it is important. We haven't talked too much about database, I know Matt's mentioned it a couple times, but I've purposely the kind of left them out because it's another aspect of the serverless stuff. So there's a lot of options now in terms of managed databases. And what I mean by that is databases that you don't have to host yourself in terms of like MySQL on a dedicated server or whatever, you can go in and use a third party service that manages the database for you. And very importantly, manages security and scaling, charting, all of that stuff for you. That's the stuff that's very complicated. When you go into a senior developer interview, a lot of the times, most of your questions will actually be about how are you going to scale this application? Where's your low balancer going to be? How are you going to scale the database queries? Where are you going to put your edge functions? Where are you going to put your separate, low balancers for the actual DNS side and the actual application side? How are you going to scale it to a point where we can go from 100,000 users to a hundred million users within two years? Mike Karan: That's a lot of the very complex interview questions that you're going to get as a senior developer. What is complicated is the scaling for sure. And these managed databases that have been competing against each other very intensely have started to get to a point where in some of those interviews, I would actually lean towards them. There's a database that I use called PlanetScale and I did a little bit of napkin math on the scaling. And it's very competitive with a highly scaled AWS installation. AWS is the cheapest I want to say, but it's also the most complex, right? So scaling at AWS instance is actually a very complicated thing in terms of scaling your databases, scaling your database connections, your servers, everything it's complex. Mike Karan: Whereas PlanetScale, something like PlanetScale is something where you kind of just give it money and let it handle the charting, the scaling, the multiple instances of your database across different regions of the world so that when one person interacts with it and updates it, another person from a different region is going to interact with a separate database, but link together with something. All of this stuff that I'm talking about is complex as hell when you start really diving into it. Because again, having a centralized database, that's easy, you're contacting that database from anywhere in the world and it's changing stuff like that. Mike Karan: When you have a distributed database all across the world so that your customers in Japan can have the same response time as your customers in Canada, that gets extraordinarily complicated because a change in your database in Japan has to be reflected almost instantaneously in Canada, right? So that a Canadian that's changing the same thing or is looking at the same thing will see the same result of that change. Again, it gets complicated. That's why these services like Firebase, Superbase, PlanetScale, DynamoDB, which is an AWS version of it, are becoming more popular and are the thing I would reach for in this kind of PlanetScale or Next.Next environment. Again, it's one less thing to manage. You're not managing another server with a database, but you're also not managing the scaling aspect and the security aspect to a certain degree of your database. Mike Karan: The other really cool thing about PlanetScale, and I want to do a whole episode on this because it's a cool service, is the fact that you can actually have branches in your database. So you can try different schemas at the same time and see which one's better. You can have like an AB testing schema. You can try schema for one, for one version of your site and a different schema for another version of your site. And then when you like one, you can kind of merge them in and it'll do that live like, so you don't have to actually take your database down. It'll merge it while your database is still up. It's a crazy service with a very affordable price. And in fact, a really generous free tier as well, which most of these services have. Mike Karan: And it's a SQL service as well, which I prefer now, I don't do as much Mongo as I used to because I think that relational databases... It's just the industry standard, SQL is just the industry standard. It's just a lot easier to work with when you have multiple different collections, right? Like if you have a user collection and a post collection, and when a user has a bunch of posts and you have that relationship to manage, it's a lot easier to manage inside of a relational database rather than a database like Mongo, which is not relational, you actually have to manage the relations yourself in that database, you have to manually put in relations every time. So it can get kind of hectic. Mike Karan: I don't want to dive too deep into that, because again, I do want to have a whole separate database episode since I've been diving into it a little bit more. But regardless, just know that there's managed database services out there that are very affordable. And like I said, I've used PlanetScale recently for that Solarians project, it was a crazy good experience. And I didn't have to spin up any servers, no server infrastructure work was done on my part, everything was handled by Vercel and PlanetScale. And it was one of those moments where I was like, when I was finished and I was like, "Okay, what do I do next?" Mike Karan: And I realized, wait, I haven't opened up a cPanel and I haven't opened up any sort of terminal to access the database. And I did it in half the time, or even a 10th of the time that I would do it two years ago where I was like, "Okay, I need to write an episode about this." I need to talk about this with people because things have changed. Serverless two years ago was not on the level that it is today, it's crazy how it's evolved to a degree where it's almost like the back of your mind you can write backend functions without spinning up a server. Matt Lawrence: This has been an eye opening experience for sure. I definitely feel myself settling back down into my servered world, though, for sure, until I have a reason to use some serverless stuff. I will say in terms of the whole load balancing thing and all that, I've set up one load balancer once from scratch ish and it was really bad. It was really annoying. So I mean, I don't know, we're not going to out the company or anything, but I don't want to do that again. And hopefully newer load balances are easier and hopefully I was just overthinking it and it wasn't as crazy. But to me, the commands meant absolutely nothing. I was typing in gibberish more or less, it felt like, and it was a bit of a disaster. So, I mean, I got it to work. That's good, with a lot of help and so having somebody manage at least that part of it is working out. Matt Lawrence: And what's interesting about all this stuff, serverless and managed database options you're talking about, Mike, and all the rest of it is that what we're slowly doing is website creation is getting so complex. We have credit cards to process and user data to store and logging people in and adhering to different laws and this and that. Just the credit card management part, the processing and holding the card number if need be is really like a job even of itself. And we're starting to sort of almost like, as the industry as a whole is sort of outsourcing it to different parts of the industry where it's like, these people deal with all the transactions and these people deal with the shipping labels and these people deal with the databases and these people deal with this. And so we're becoming the driver of the car, we're not becoming the engineer, the designer or the mechanic of the car, if you will, which is- Mike Karan: That's exactly it, I think you nailed it right there. Matt Lawrence: Boom. So yeah, it's interesting to see this type of stuff. I am stuck in my ways as to an extent, but I do hate maintaining servers. I don't mind setting them up and playing with them, but I don't like maintaining them, especially in production. So maybe I will have my thoughts changed at a later date. Matt Lawrence: But I think that really concludes it. I've asked tons of questions. I'm sure I'll have more, Mike wants to cover more of these more specific topics in future episodes. And I'm sure this will come up once again, probably with some sort of disaster that I tried to spin up some sort of serverless thing and Google stopped working somehow. So we'll see what happens. But if you interested in episodes like this in episodes like I just mentioned like that in the future, please come check us out on Patreon on this patron.com/htmlallthethings. Matt Lawrence: And thank you to our current $3 tier, patrons Ryan Gatchel from Blue Black Digital on blueblackdigital.com, Chris from Self-Made Web Designer on selfmadewebdesigner.com, Tim from The Web Hacker on thewebhacker.com, D.L. Ford from dlford.io, [inaudible] from mind block media on mindblockmedia.com, Jason from Geek Life Radio via geekliferadio.com, Michael Currie from MC Webs Studio via mcwebstudio.ca, Magnus from Yes Web via yesweb.se and Jeff from Twitter via @TheJeffMcale. Matt Lawrence: Please leave a comment or review on the platform that you are listening to the on and we are signing off. Speaker 1: You've been listening to HTML, All the Things podcast. Web development, web design, and small business. We hope you've gotten some useful and practical information from this show and we hope you appreciate that we talk to you like human beings and we hope you had some fun. We'll be back soon. But in the meantime, hit us up on social media, on Facebook, Instagram, and Patreon at HTMLallthethings and on Twitter @HTMLeverything. Until next time, this is HTML All the Things signing off.