Kate: James Q Quick: Hello, PodRocket listeners. This is Kate, the producer of PodRocket. Today we're feed swapping with Compressed.fm, a weekly podcast focused on web development and design with a little bit of zest. This podcast was born out of a passion for teaching shared by the two co-host Amy Dutton and James Quick. In this episode, James and Amy talk about everything serverless and how it fits into modern web development. They discuss serverless functions, Edge functions, hosting platforms, frameworks and tools, benefits and more. We hope you enjoy the episode. Welcome to another episode of Compressed.fm, a podcast all about web development and design with a little bit of zest. In this episode, we're going to talk all things serverless. Web development and design, who would of guessed? Well we can do on both, even add a little zest. So turn up the volume, get ready for the best. Let's get it started in this episode of Compressed. Amy Dutton: Hello. My name is Amy Dutton and I am the Director of Design at ZEAL. James Q Quick: What's up, everyone? My name is James Q Quick. I am a full-time technical content creator. Amy Dutton: So, James, what have you been up to? James Q Quick: Well, I told you before we started recording, I would tell you my little story about travel updates. So we have our offsite for the marketing team in Austin. In two weeks, I'll be traveling four weeks in a row. I'm at Remix Conf this week, leaving tomorrow which is going to be super fun. And then I have RenderATL the week after which I'm also super excited about. The week after that we're going on vacation. So my sister is renting, I don't know if it's a cabin, but it's kind of a cabin-ish house thing in the woods in Arkansas. And so we're going to do that with her family. And then after that is the offsite in Austin. So I think those are the four weeks, if I said that correctly. And I was supposed to be gone Tuesday through Thursday where we'd fly in Tuesday, have a thing that night, do Wednesday all day, do something in the morning, Thursday and fly out in the afternoon on Thursday. And I was talking to my VP about kind of figuring out what my voice is when I give talks and how do I include PlanetScale on a natural way? And he was like, "Why don't we do a workshop type thing?" So we added a workshop that Thursday afternoon, meaning I would stay another night in Austin. And so I was looking at return flights and I was talking to Jess. So I would come back on Friday. We record our live episodes on Friday and I was trying to schedule my flight around that so I'd probably record the episode from the hotel room. Amy Dutton: That's very kind. James Q Quick: Yes, you're welcome. So I was telling Jess, I was like, "Well, I think I'm going to be flying back, leaving in the afternoon and getting home at 8:45 or something." And she's like, "Huh, I get home at 8:45" because she's going to London that week to be at her offsite. And one of my options was to fly from Austin to Detroit which is out of the way. But from there, I would be on the same flight home with Jess to Memphis. So she's coming back from London and I'm going from Austin back home and we'll meet in Detroit and then fly home from there. It's kind of crazy. Amy Dutton: That's so sweet. James Q Quick: Yeah, I know. Amy Dutton: What a rendezvous. James Q Quick: Yeah, that's kind of cool. It's an extra hour of flight time because I'm flying way out of the way, but I guess it's worth it. Amy Dutton: I guess. Do you watch Modern Family at all? James Q Quick: No, I've never seen Modern Family. Amy Dutton: You should watch it. You would love it. James Q Quick: I've heard of it. Never watched it. Amy Dutton: So one of the dads, Phil, he has this alter ego with his wife that they kind of have little rendezvous, but his name is Clive Bixby. James Q Quick: They have their alternative egos for that. Nice. Amy Dutton: So you said that and that's what I thought of. James Q Quick: We can do that thing where I pretend to pick her up like we're strangers and I hit on her at the bar or something. Amy Dutton: Yeah, that's exactly what they do in the show. I'll send you some of the specific episodes. But in my mind, they're some of the funniest ones. Oh man, I'm not going to go into detail, but I will send you the specific episode. James Q Quick: Yeah, do that. I can tell you Jess is not going to be into that. She's not a super flirty person. So pretending to flirt with a stranger that she's been married to for six years is probably not her wildest dream. Amy Dutton: I'm not either, but just that show is so funny. What is interesting on that note is today marks kind of our 11 year anniversary. So 11 years to this date we had our first coffee date at Starbucks. James Q Quick: Nice. Congratulations. Amy Dutton: Thanks. James Q Quick: How different is that from actual wedding anniversary? How far off? Amy Dutton: That's a good question. A year and a half. James Q Quick: So you've been married about nine years. Amy Dutton: I think that's right. Yes. In September it'll be 10. James Q Quick: We're not too far behind. We're six and a half. So one day we'll catch you. Amy Dutton: When we die. James Q Quick: Actually for us to catch you as a very morbid take on that. So Amy, what have you been up to? Amy Dutton: What have... Oh, I had a good answer. James Q Quick: Yeah, make your life sound exciting. Amy Dutton: As if it's not already. So this is fun. We had a group of students that were in high school when we were in Chicago come down and visit us. So they're all college students now. So Friday night we hung out with, I don't know, six or eight college students. James Q Quick: Nice. Amy Dutton: But it was so much fun. We played Jackbox Games. So I don't know if you do that on the PlayStation. So hilarious. James Q Quick: That's fun. Amy Dutton: I'll tell this quick story. I promise it'll be brief. So I think people know I have a King Charles Cavalier named Peanut and my kids have shortened Peanut's name to Peeny which is incredibly uncomfortable sometimes. James Q Quick: Oh boy. Amy Dutton: So when he starts shedding, he leaves peeny hairs all over the house. James Q Quick: Oh, no. Amy Dutton: So anyways, that was the big joke while the college students were there because they were talking about Peanut's peeny hairs. James Q Quick: Oh, gosh. Amy Dutton: That might not be an appropriate story, but... James Q Quick: That's one way to kick off the podcast. Amy Dutton: We might take that out. James Q Quick: Or we'll keep it. Amy Dutton: Make it family-friendly. So I do have a rant for this week and I'm kind of excited about. So I got into a discussion with a colleague, coworker and it was kind of interesting because we got into a discussion in front of three of our interns. James Q Quick: For what it's worth, Amy told us as an argument earlier and now she's downgrading it to a discussion. But go ahead. Amy Dutton: A discussion. It was a very opinionated discussion. So I had submitted a pull request and my colleague was reviewing my pull request and his feedback was that I needed to take out all the comments in my pull request before he would merge it. And I made the comment, I love comments in my code. He was arguing that it was tech debt and unnecessary. And if my code was good enough, it wouldn't need comments. So I was arguing that so I can read code, but I can read English faster than I can read code. So I would prefer to have comments there so I can kind of skim through. And if it's tech debt, it should have been, he was saying, if the code gets updated and somebody doesn't update the comment, then you have bad documentation inside your code. And I was like, "Well, they should have updated the comment if they changed the code." But I was just saying, I felt like it was also the empathetic thing to do. And it was kind of interesting because we had this conversation in front of interns. And so the interns were like, "Yes, please. Comments are good." But I was just saying as somebody new to code, the empathetic thing is to explain what you're doing so that they can come in and they know how to update things. So anyways, it was just interesting. I went down a rabbit hole of looking on Google and just seeing what do other people say about this and just trying to be open-minded about everything. And one of the interesting points that I read was somebody was saying that your code is how you do something. A computer can execute lines exactly as you describe but what it doesn't understand or it doesn't convey is why. And so really, if you are going to include comments, it should explain why you made certain decisions so that the person coming behind you understands that. And that's what code can't tell you. So what side do you pick? James Q Quick: I take the opposite side of Amy. I think it's like... No, I don't actually. It's one of those, personally I think saying if your code was good enough, it wouldn't need comments. I think that's silly. And I think that comment specifically is judgmental and condescending to start. There are techniques to make code more readable. One of the things that I'm a big fan of is longer variable names that are very descriptive of what the actual thing is. And I learned that from one of the best developers that I had ever been around. And if it was like map object in Java, the name of it would be person name to profile map or something. So you know exactly what the keys are and exactly what the values are. I think we're less at a stage of needing comments the way that we were taught comments 10, 15 years ago. At that point, and especially the guy was like, "You should be commenting your code. You should have comments all over." And we were judged on that on homework assignments, for very simple stuff. This function adds A and B. That doesn't make sense. So I think the real need for comments is a lot less than it was several years ago. And I think there's things you can definitely do to improve readability and kind of get rid of some of the comments, but there's also just situations where I think it's helpful to have... So I kind of always play the middle ground in every situation and debate. See, I think it's easy to say you don't need comments and just kind of shrug it off. I think it's more practical to say like, "For this exact situation, here's what we could do... And then our code would then explain what your comment is explaining. Like here's some tweaks we could do." But at the end of it, it all comes down to the team too. And unfortunately, when you're in a discussion, you have to figure that out what's going to work for your team. So you going to take my answer back as proof of... Amy Dutton: James said. James Q Quick: See, I told you. Yeah, James said. Amy Dutton: James said. James Q Quick: We should start a segment called James said. Amy Dutton: What was funny was he referenced another coworker that no longer works at ZEAL. And he was like, "So and so is on my side with this." Because I had said that this person said the same thing to me. But what was funny was the person that he referenced, we were pairing on some code at one point and he was like, "Comments on this would've been helpful." And I was like, "You just said never have comments." And then you came back around and was like, "Well, in this instance, it would be a good thing." So I think here it depends, it's a standard developer response, but it is true, it really does depend. You don't want to put so many comments that it is unreadable and hard to maintain, but so few that it's hard for somebody behind you to come in and follow or make updates. So speaking of updates, an update in tech lately is serverless. James Q Quick: Nailed it. I like it. Amy Dutton: Awesome. James Q Quick: So I mean, it's one of those buzzwords we hear all the time and the more you get into it, I think the more intricacies you start to learn. And the modern web development ecosystem is really exciting. I say this a lot. There's never been a better time to be a web developer. There's so many amazing tools and platforms and things are just becoming easier and easier, which is like serverless plays a big part in that. And the overwhelming part of that is there are now these new techniques to understand and these hybrid frameworks that we'll talk about. You have to understand what code is running where and why and how and what the trade offs are and all those things. So I guess we could just start with the general idea of serverless. And I'll do this slightly out of order. Thinking about what you would do before serverless. When I was at FedEx, we had our own server so our own actual machines that we purchased and that we had located at the hubs where we sorted packages. So this was sortation software that we wrote and we had actual physical servers that were inside of the hub. And this was a big latency piece where we had to have those servers really close to the machines that they were talking to which are the physical sorters. But what that means is we have to figure out how many servers and what type of servers we need and what type is like how much RAM, how much storage, what kind of processors, all those things, what sort of workload are you going to be running on these servers? You have to know that. You have to then order them yourselves. And then it's your responsibility. We had an IT admin or I don't even know what they were called, to be honest, like an IT admin team that would do patches and updates and they would do refreshes on machines. And that's all stuff that someone on your team or at your company, unless you outsource it, has to take care of. And that also means for us to deploy things, we've talked about how nice and neat deployment processes are. And actually in the last episode, we talked about the pipelines that you can get going automatically. But for us, we physically had to build some sort of JAR file in Java and we would have to take that file and send it over to that machine and do all the manual things to get the application up and running. So all that stuff is just things that you have to manage. It's people's time, which is one of the most expensive things in the world. Another problem with that is, let's say you buy a machine or two machines or X number of machines and they're Y powerful, however powerful they are. And you hit a load or at scale where now your machines just can't keep up with what you're doing, but now you have to buy just brand new machines, you don't really have a choice. Now this is called scaling up. Now you have to buy bigger machine. You have to buy more RAM, more storage, et cetera. And that has its limitations. You'll kind of hear this idea of scaling up versus scaling out or vertical scaling, which is scaling up and horizontal scaling, which is scaling out. And it's the difference between trying to solve a problem by buying just a bigger, more powerful machine versus the alternative is to just buy more machines and run this stuff across more machines, because it's much closer to infinite amount of small machines that we can make versus how powerful we could make one machine. There's only so much RAM you can have. There's only so much hard drive, no matter how much you pay. So where serverless comes in is all those things that you would have to manage from a server perspective. Now you don't have to manage. So a couple of good examples in here of companies that do this. One, there's the major cloud platforms. So there's Amazon AWS, there's Microsoft Azure, there's Google Cloud. Those are the real big three major cloud platforms with AWS being number one. And then just thinking about, okay, what if I want to run a node project? This is something that we talk about a lot and look at ourselves, where can I run that in a way that I'm not actually having to deploy a machine? I'm not having to pay for an actual server itself, physical server itself. I'm not having to manage updates and patches and all those things. And there's lots of really cool examples of hosts like this. There's DigitalOcean, Heroku is where I host my Discord bot. You talked a lot about, in the last episode about Render, which is where you're hosting a project for work. There's Fly.io. There's lots of these services and what they allow you to do is to click on a button that says, I want an environment. I want a virtual machine, basically with Node installed on it and maybe you have something more specific where I want Node and Postgres, et cetera. And then they just give it to you. There's nothing else that you have to do. It's just there for you. Now you have access to it and you can take advantage of it. So the highest level definition of serverless is not that there's not servers involved, it's just that you, the developer or you, the team, you're not actually having to manage those servers directly. Amy Dutton: I think people take that for granted. As you were talking, I was remembering in 2012. So again, this makes me the internet grandma, but in 2012, Hurricane Sandy came through the East Coast and Squarespace has this crazy story about how their building, where they had all of their servers got flooded and they had to move the servers out of the basement up and try and fuel their generators all night long while they were pumping out water out of the basement. So I mean, everything that they had to do was really a story that goes down in Squarespace legacy, all the trouble that... Went to maintaining that. And people forget that because now it's just click a button. I have a server or upload a file. There's my server. James Q Quick: And that's another good point. I think a lot of this goes back to cloud fundamentals like cloud computing. What is the cloud? How does the cloud work? What does it offer you? And what are the benefits? And to your point, a lot of these cloud providers, all the ones that we talked about so far enable you to have that ability to spin up VM, virtual machines, get your own environment that you can deploy stuff to not only quickly and easily, but they also have the ability to replicate that. So they can replicate your application in different availability zones. This may get a little technical, but an availability zone is different zones inside of the same data center, but they're completely separated by network and power. So if the network goes out on one availability zone, it doesn't necessarily affect the other. I mean, if there's a really massive problem, then maybe it does. But the idea is you can have your applications running across these multiple availability zones, which maybe be in the same data center, may be in the same region, may also be cross-region that gets a lot more expensive. But that way you kind of open yourself up to, if something disastrous happens to this one availability zone, I still have an instance of my application running in this other one. And hopefully that one is still going so that you're not having to manually move servers out and run generators yourself. You're really betting on the cloud provider, whoever it is, to take care of that for you. Amy Dutton: I didn't realize that that's what the zone stood for. Whenever I've signed up for a DigitalOcean server and you can pick the location and the zone, I didn't realize that that was the 1, 2, 3 piece. James Q Quick: So when you pick, you may not actually be getting that deep into the availability zone, because a lot of the free stuff is just selecting a data center, not necessarily showing you specifically what the availability zones are. Because you can have availability zones in the same data center, again, separated by network and power and in a different building probably. So probably most of the things we'll talk about today that we'll see is the ability to choose your data center. And for what it's worth, I don't know if this is super obvious to a lot of people, the reason you choose a data center in a specific region is because of literally the speed of light. Even though it travels very fast, data can only travel so fast. So if I'm in Memphis and I'm trying to load a website and that website is hosted in New York City, that's relatively fast. If I'm trying to load that site from Memphis and it's in Tokyo, Japan, that site's going to be a lot slower. So there's literally this speed of light problem where now all of these data centers across the world and there's more and more popping up, I don't know, every day, but every year, having those different data centers in different regions of the world now open up the potential to have more and more performance inside of these applications. Amy Dutton: So when you pick a location, do you just pick it closer to you? Or are you trying to pick closer to wherever the majority of your customers are? James Q Quick: So it would be the majority of your customers. So you want wherever the majority of your customers are to have the best experience that they can. And we'll talk about, we've got a note down here for the Edge, which is even more mysterious and I think understood, not understood even more so than just the general idea of serverless, but the Edge is this idea of replicating the code everywhere across the world so that no matter where people are, they get the fastest version, but there's limitations in that. But that's the general idea is you want stuff to be as close as possible to the people who are actually using the application. Amy Dutton: And the Edge is not Microsoft Edge browser, right? James Q Quick: Different. Yeah. This is more generically like Edge computing. Amy Dutton: Like Web3, right? James Q Quick: Web3 doesn't inherently have any dependency, I think maybe conceptually, but not necessarily technically, if that makes sense? Amy Dutton: Okay. Yep. James Q Quick: I think you're talking about the idea of the distributed ledger type thing where everybody has a copy of what's going on versus this is actually running compute across the world. Amy Dutton: Got it. James Q Quick: But Web3 may take advantage of the Edge to do that. I don't know. Fun times. So we talk about serverless again, highest level definition. It's not that there's not servers it's that user developer, you, your team are not having to take care of actually buying physical servers, updating physical servers, et cetera. But I think the really exciting thing is when we get into serverless functions specifically and serverless functions is the subset of the concept of serverless that are literally just functions that run inside of a virtual machine somewhere. And most likely you have no idea specifically what machine that serverless function is on. You would just potentially have that same concept of what region those serverless functions are running in. But before we do that, I want to kind of lead up to where one of the needs for the concept of serverless functions comes from, and that starts with this idea of the Jamstack. And Jamstack is another one of those buzzwords that gets talked about a lot. Jam stands for JavaScript, APIs and Markup. And the really interesting thing, Jamstack is kind of a revolutionary way of how we build websites and how we think about building websites. But a lot of the underlying technologies are not necessarily new it's just we're now using them in a different way than we ever have before because we've realized we can do it in different ways and get different benefits for specific scenarios. And Jamstack really has this focus at least to start on static content. And I define static content as anything that could be hosted on a CDN or a content delivery network. And what's interesting static content doesn't mean static experiences. So like React, Angular, Vues felt they have a build process where the output of that is just HTML, CSS and JavaScript. Those are static assets that can be hosted on a CDN Amy Dutton: And basically has to be like HTML, CSS, JavaScript and that's it, right? I don't think- James Q Quick: Yep. And... Amy Dutton: It can be anything else. I mean, it might get rendered down or compiled to that, but I mean, that's all you're delivering. James Q Quick: That's the output. Yeah, exactly. And that means no real time server interaction is basically what that comes down to. So we saw the static site generator's concept really became popular. Gatsby was one of the hottest ones. That's what I ended up building my website with. I think you built your website with Gatsby, at least at some point and tons. I just remember there was this period of months where it's like, "I just built my new blog in Gatsby." "I just built my new blog in Gatsby." Everybody was posting about it on Twitter, which was great. And so we got into this point of really getting into this statically generated content. So we take the idea of React. We build on top of that to not only are we going to figure out all this content on the browser, we're going to go ahead and figure out all this content on the server at build time, build all of these individual pages. And now they're just pages that are ready to be loaded instead of a big bundle of JavaScript you would get with regular React that ships down to the browser. And then we kind of realize that we need to do more, not every situation calls for just purely statically generated content. And how do you do things like interact with a database? If you need to interact with a database real time, not just at the statically generated part during the build process, how do you handle your private environment variables and things like that? You can't include environment variables and JavaScript that goes to the browser because people can find them. Amy Dutton: We have an episode about that too. James Q Quick: Yes, we have an episode all about secret credentials and I forget the full title, but all about that stuff. Amy Dutton: Secrets. James Q Quick: That's right. So this kind of evolved to static site generators are great. They don't cover every use case and we kind of need this ability to do stuff on the server. And this was kind of the perfect storm for something that had been around for several years. And then just kind of really took off in the Jamstack ecosystem, which is this idea of serverless functions. And we kind of chatted behind the scenes before we started where you were like, "I've got some questions because I just accept the magic that goes on." And this is literally the quote that I use for serverless functions. When I explain them, it's like you write literally a function and then magic happens. You're not having to write a full Node server. You're not having to define all of your routes, mostly. You're not having to do all these things that come along with actually writing a full Node server. You're literally just writing a function and that gets hosted behind the scenes on a Node environment that's run in a serverless function. Amy Dutton: Yeah. That's magic to me that you just have a single function on a server running somewhere and it'll do the thing that you ask it to do or return the value that you need. So I know that a lot of the hosting environments that we love like Vercel and Netlify even have special ways of handling those serverless functions. James Q Quick: Yes, so those are probably the best examples, at least in kind of the ecosystem that we're in. I guess I think by and large AWS just in general dominates this whole cloud ecosystem. But for the tutorials that you see, the blog post that you see, the content that you're seeing, that's really modern. You'll see a lot of Netlify and Vercel and CloudFlare is another one. And there take on serverless functions is a little different. They actually take advantage of the Edge. And I'll talk a little bit about that. I'm not an expert in anything, but I know a little bit less about that, but I will talk about that a little bit in a second. Amy Dutton: Let me ask a quick question. Are you familiar with Lambda? James Q Quick: Yeah. So that's actually a great question. Amy Dutton: Okay. I was going to say, how does that fit into everything? James Q Quick: Yeah, great question. Yes, this is something I meant to call out and I forgot. So you are putting us on the right path. Amy Dutton: Perfect. James Q Quick: So Lambda is the name that AWS has for serverless functions inside of AWS. Now I mentioned AWS really kind of dominates the cloud ecosystem and the benefit of AWS is they do freaking everything. You can have VMs, you can have databases, you can have serverless functions, which they call Lambda. You can have all these things and they can talk to each other and you can do all sorts of security things with them and rules. And I mean, it's a ridiculous ecosystem of everything you could possibly want to do in a cloud environment, AWS gives it to you. The downside is one, the dashboard is historically really a pain to work with. And a lot of that comes from the fact that they've got so many freaking things that you can do that it's impossible to have this amazing user experience across every one of them because they're just shipping out. Here's a new thing. Here's a new thing you've never heard of that you didn't know you needed. It's really big and it's really intimidating. So for me specifically, I've almost never worked directly with AWS because there are tools that make that stuff so much easier. Like Netlify, Vercel. I don't know how CloudFlare runs theirs. I don't know if it's Lambda exactly, but, Netlify and Vercel what they call serverless functions actually runs on top of, or actually uses Lambda functions in AWS. So if you were to use Lambda functions and AWS directly, you'll have tons more configurations that you can do. You can do all those integrations between it and other pieces in AWS. With serverless functions in Netlify and Vercel, which are abstraction layers on top of Lambda, this is where that magic comes from. So I'm not having to write a configuration thing for my functions that AWS can read and work with. I'm literally just, as we said, writing a function or putting code in a specific file. We'll talk about frameworks in a second, and they take care of the rest. So they are actually provisioning those Lambda functions behind the scenes for you and taking care of all that, which makes the process all that much easier. Amy Dutton: Cool. Yeah, so with Netlify, you just have what? A folder that you upload that to and then Vercel, you have your API folder inside Next.js that's serverless, question mark? James Q Quick: Question mark. Those are probably the traditional ways to set up. But so when I first started with Netlify, it was really kind of a static host where you could host your React app, you could host, et cetera, but then when they added serverless functions, now you could have that kind of server, basically their HTTP endpoints that you define functions for. And you take in the request and you send the response back. An example of that would be on my static site I had an email thing when they clicked subscribe, they would send the email to my serverless function. They would do the work to actually add it to mail champion and it would respond back to say, "Yay, you subscribed." Those are typically configured where you tell Netlify and the netlify.toml file. My serverless functions are inside of this directory. Oftentimes you'll see that directory called function. So if you're looking through a repo and you see a functions directory, that may be an indicator that that's someone that's hosting it on Netlify. Now the caveat to that though, is that things like Next.js and this is where we get into frameworks, but Next.js is a hybrid framework. It can do statically generated content. It can do SSR, server-side rendered content and inside of it has this built in idea of API endpoints. And so in Vercel, as you said, you have an API folder and all of those files inside of that API folder are then kind of registered as API endpoints. Assuming you create the function in the right way, but mostly that's what you'll see, API directory, all of those files inside of there are basically HGTP endpoints run on serverless functions. So if you were to deploy Next.js to Netlify, there is an adapter. And I think what happens with that adapter is it just translates those files into the format that Netlify is looking for. And more specifically, it may just be telling Netlify in the netlify.toml configuration, "Hey, your serverless functions are in this API directory." So instead of them being inside of functions, which is not a requirement, that's just what you typically saw. Now they're in the API directory inside of a Next.js project. And there's probably a little bit more that goes on with that adapter, but that's probably mostly it. Amy Dutton: Clear as mud. At least clearer than it was before. It's like, don't look at the man behind the curtain. You just pulled the curtain back. James Q Quick: Well, yeah. And I think this is still kind of the point though. This is one thing that I've gotten really into. This idea that developer experience is just making all of this stuff easier and easier. And again, if you were to do this with just AWS Lambdas by themselves, you have to understand a lot more to be quite honest than if you're using Netlify or Vercel or CloudFlare, et cetera. So they make it a whole lot easier. And that's kind of the point, right? There is magic. It's cool to learn about. It's kind of good to understand what's going on, but also the point is that you don't have to. That's the whole point of all of this stuff is we can take care of some of the "hard stuff", so you can go and build your application. So we kind of started down the idea of frameworks. So we've talked about Next.js a lot. We use Next.js for the compressed FM website. I started a rewrite of my website from Gatsby to Next.js that I haven't finished, one day I'll get to. Amy Dutton: About with that redesign. James Q Quick: Yeah, as soon as I get that redesign from Amy and we've talked about Spelt kit on the podcast, we've got everything Spelt course that we're working on. Remix is another new hot one that we're going to do a deeper dive into in the next couple of months so look forward to that one. And these are all frameworks that have the ability to kind of support this concept of serverless functions. And Gatsby was one of those ones that they didn't want to call themselves a static site generator, that's really what they were and that's really what they became known to be. And at some point when they got funding and I think we're kind of looking at Next.js and its ability to do both static content and server side rendered content. Well, I think Gatsby realized they had to do that too. So I haven't used this. I haven't looked at it really in depth, but Gatsby now has this idea of serverless functions in API endpoint in a similar way that Next.js does. I don't know, have you looked or seen anything about that or just the fact that it's there? Amy Dutton: Yeah, I switched from Gatsby to Next.js right before they made that announcement. But part of the reason that I switched was because of the build time for that Gatsby was taking. And I think that that's probably maybe one of its biggest criticisms was that build time. And so the fact that you could rely on the server to generate stuff instead of having to statically build everything and wait 10 or 15 minutes for your site to build was a big motivator for them to update their stuff. And another piece that they did drop with all of that was how you handled images in their image component and image server. James Q Quick: And that was really, I don't know how much attention people out there that are listening, paid to this, but it was very obvious that Gatsby at that point was playing catch up because I think they really thought they were going to take this statically generated content thing all the way. And Next.js, like I said earlier, everybody was building their blog and Gatsby including myself. And a year later everyone was talking about Next.js and I think Gatsby realized that and they had to start making changes and it seemed like catch up. And there's like, you see this all the time to be quite honest, if you look at a series of cars, like brand new cars against different makes and similar models, every time they change every three or four years across different makes. You'll see similar changes that come out. And it's really interesting because the idea of innovation I feel like is actually very rare because it's like someone comes up with an idea and then collectively they're like, okay, we need to be doing that because that's what people want. And I think that's exactly what happened with Gatsby, looking at Next.js and realizing they've got some things that people are loving, people think they need and I think rightfully so and we've got to now play into that and play catch up. Amy Dutton: Well, it's kind of interesting the frameworks and libraries that have sprung up since then and the opinions that they have taken. So for example, Remix has come up since then and they've decided that they're going to be completely server side, that it's not worth your time necessarily to be static or the benefits aren't as good as you think they are. And so it's just kind of interesting the different opinions that different frameworks take. James Q Quick: Yeah. Remix is a really interesting, I encourage anyone. If you want to learn more about how the web works, read the Next.js versus Remix blog article, it's really kind of mind blowing and their whole thing. We won't go too deep into this because we're going to talk about this in the next month or two I think, but their whole thing is statically generated content is honestly not that valuable, if you can take advantage of caching in, I honestly don't know if it's in the browser specifically or if it's at the CDN level or whatever, but basically you can use native caching techniques to be almost as good or better, honestly then your statically generated content that you're used to. Amy Dutton: And we'll include a link in the show notes. James Q Quick: Cool. So let's talk a little bit about benefits of serverless and serverless functions specifically. So one big one I think is the ease of use and developer experience. And we've talked about this already a couple of times, but you've got frameworks that have this concept already embedded into it. Serverless functions specifically. You've got hosts that are just amazing UIs and functionality on top of something like AWS, which is historically difficult to work with. So you've got Netlify, you've got Vercel, you've got CloudFlare, you've got all these frameworks that are popping up to just make it easier for you to build stuff. So the ease of use and the developer experience. I said this earlier, it's never been a better time to be a developer. It's never been easier to create something really amazing than it is right now. And I think it's only going to continue to get better. And that's the really exciting thing. The other thing is that you only pay for what you use and this will actually lead to I'll talk about a little bit of the downsides here in a second. But the idea with serverless functions specifically is that you have, if you invoke the serverless function means someone calls your serverless function, which is most likely an HTP endpoint. Someone makes a request to that. Serverless function may not have already been running, meaning it's going to have to start up then handle the request and send back the response and the benefit of that. If you think about these ups and downs of traffic. If you get no traffic during the night, but you have lots of traffic during the day, if you're thinking about a specific local time zone. If I were to buy my own machines, I would have to buy a machine powerful enough to run constantly, to be able to handle the max load. And thinking about the example at FedEx, FedEx is a shipping company. So busy times for us are Valentine's day and Mother's Day and Christmas and Black Friday and when Apple launches a new iPhone, believe it or not, that's something that FedEx is very aware of because that's a lot of iPhones that are going out all of a sudden when those things launch. So those are things that people have to consider. And again, without this idea of serverless, you would have to have a machine big enough and powerful enough to handle your max load even if your max load is only 1% of the time, even if it's only one day out of the year or if it's only 20 days out of the year, it's got to be able to support that. So this idea of serverless is saying, we can handle whatever you want to throw at us. So we will scale up to handle your request as they're coming in at a really high rate, then we'll scale down when there's no request. So you're really only paying for what you're used and you're getting this hypothetically infinite scale of resources that can be supported. Amy Dutton: And I think Heroku does that. That's been their biggest selling point. James Q Quick: Yeah. So Heroku. So it's selling points slash pain point, I think. Because if you were to host a regular website on Heroku, what they do is if I think it don't quote me on the thresholds, but something like this, If you don't get a request, if your website doesn't get any activity in 30 minutes, it basically shuts the whole thing down, which mean this is on the free tier, by the way, it doesn't happen if you have a paid tier and I have now upgraded my tier for the discord bot to pay five bucks a month or whatever, so that this doesn't happen, but it shuts it down. So it's just like idle, it's sleeping, whatever you want to call it, you actually see this in things like Supabase things like PlanetScale. You probably see this a lot. If you're using some of these tools, if you don't use the application or the database or whatever it is in a week, they'll put it to sleep. And then you come back to your dashboard and it's like, Hey, your thing is asleep. Do you want to wake it up? And so there's a manual process in Supabase as I go through a week without testing for the everything's swell of course. And I come back, I've got to turn that thing back on. And that's for them to save money because they don't want to pay for resources to be running at all if you're not using them. Amy Dutton: Especially on the free tier. James Q Quick: Yes, exactly. And I've learned that free tiers have a lot of burn rate, I think is what marketing people and sales people refer to as how much does it actually cost to support the free tier because you want to have a free tier to have people test out the product and hopefully love it. And then go to work and say, Hey, we should use this product, but that also does cost money. It's not a free thing to the company itself. So those are some of the benefits. There are downsides. I think we get into this world of people talk about new technologies and ideas and methodologies and frameworks and everything's perfect and that's never the case. So a couple of the downsides, there's this idea of startup or cost or cold start. And what that is let's say your thing is sleeping. Going back to the Heroku situation. What people get bothered by is people don't come to a website for 30 minutes and the next time they do, Heroku's having a start, all that stuff up, which means now your load of your website goes from a second. What it usually would or whatever it's now five seconds or something, because it's actually booting up the entire virtual server that it's running on. And that's with more of a full Node server. For example, in the serverless functions world, you're not worrying about a full server specifically and I couldn't even tell you exactly what the difference is behind the scenes, but there's still this startup cost of if fewer serverless functions are cold, they haven't been called recently. It has some sort of startup that it has to go through to then be able to handle that request and send back the response. So it takes, I think it's fairly minimal, a hundred milliseconds. I don't quote me on the number, but the startup cost there is relatively low, but it's still something. Heroku is a much noticeable difference on the free tier. But most serverless functions have some sort of delay it's in the millisecond range, but it's fairly negligible, but it is still there. A couple of additional problems that you'll have, if you've ever written software, non cloud-native software, it's just running on a computer. You can do things like access file storage on the machine. You can store stuff in memory to do in-memory caching, et cetera. And all of that goes out the window when you have serverless functions because these serverless functions are spinning up and they're spinning down and they have no persistent state, meaning you can't have anything in memory, any caching. You also, typically in cloud-native environments don't have access to the file system. So if you were looking to write something to a file or read a file, you'd have to use some sort of external service. Amazon S3 is the biggest example of that. That's the most common, I think, of just storing files in S3. So those are a few things. Another thing that you don't get is this idea of persistent connections. So you can have a serverless function again, spinning up and spinning down. As it spins down, it's not then able to maintain a connection for something like a discord bot. So I would love to run my discord bot in serverless functions, but the discord bot is dependent upon a persistent connection to discord so that it's streaming in those messages as they happen. So you can't do that in a serverless function environment because it can't maintain that connection. Similar thing with databases, it can't maintain a long standing connection to a database because it's spinning up and then it's spinning down. Amy Dutton: But you could set up like a webhook listener or something like that. That would then ping the server when say a specific URL's triggered to do a bunch of things, right? James Q Quick: In the discord example specifically? Amy Dutton: No. Well with the discord, it would have to be- James Q Quick: Because I think you actually can with discord. I think they have the idea of callback functions. Amy Dutton: Okay. I was just thinking like say somebody posts the YouTube video and you have some hook maybe on Zapier that looks for when that YouTube video gets posted. And then it pings the serverless function URL to trigger whatever action. James Q Quick: Absolutely. And that is a very common pattern. Amy Dutton: That does require another service like Zapier to actually listen out for that thing. James Q Quick: Yep, so it's doing that constant listening. And probably what they're doing is just a polling cycle of it's checking every five seconds to see if there's something new. Amy Dutton: Yeah, I think that's right. Because on their paid tiers they will tell you that they'll run stuff faster. The higher up you get- James Q Quick: They'll do the check more often. Amy Dutton: It's like 15 minutes on the free tier, five minutes on the paid tier, something like that. James Q Quick: So the last bullet I have is on Edge computing. And I remember Next.js or Vercel actually in one of their big announcements, talked about Edge. And I finally just posted on Twitter. I was like, what in the world is the Edge and the difference between Edge and serverless functions. So serverless functions I learned, which does make sense. Serverless functions do run in a specific region in a specific data center. What you don't see though, is things like Netlify and Vercel, when you create your project, they're not presenting you with a UI of what region do you want to run this in? If you go to Heroku, if you go to a lot of the other services that are less abstracted, they're at least asking you, what region do you want to run this in? And there may be setting in Vercel. I assume there is where you can control the actual region that you're running it, there has to be. But it's not something you have to manually decide on. As you're deploying something is my point. So what happens? Those serverless functions are running specifically in a region. So if they are deployed, you'll see U.S. East is a common one. That's usually in Virginia. If my serverless functions are running in Virginia, again, this idea of the speed of light is only so fast. If I have a user that's in Japan, that's trying to make a request to that endpoint. It's got to travel all across the world. Before it can respond. The idea of Edge is to basically be able to run this concept of serverless functions at the Edge, the Edge being closer to the user, no matter where they are. So that means in theory, your serverless function, that logic would be replicated all across the world. So that if you're in Japan, you would make a request to the end point and somewhere along line internally, the DNS can figure out which way to route that request. I've never fully understood this, but DNS would have some sort of record of like, all right, you're making a request to this endpoint. I know that we've got code for this endpoint running at all these different locations. And I know where you're making the request from and it's able to calculate if you are in Tokyo, if you're in Tokyo, Japan, we will not forge your request all the way over to U.S. East in Virginia, we will then send you directly to Tokyo. The key thing for me that I just didn't realize at first was the fact that Netlify and Vercel those serverless functions, even though you're not choosing a region or you don't have to manually choose a region, those are running in a specific region and not replicated across the world. I did a video with CloudFlare on their CloudFlare workers, which is their serverless functions. And I remember them talking about how much faster they were and not really understanding why until I understood the Edge because CloudFlare's thing is that they run their CloudFlare workers at the Edge, which means they're replicated all across. I don't know how many places, but in places across the world for that point or for that benefit of speed, the problem is not problem. But one of the downsides of that is that they don't run a full Node environment. And I don't even know what the specific details are of what that environment is, but it's not your regular Node backend JavaScript environment. It's more of kind of a browser JavaScript environment. And again, I'm not going to be able to nail the specifics here, but basically you don't have access to all the APIs that you would if you were in a full Node.js environment and you don't have all the APIs of the browser and you can't use all the NPM packages that are out there. So some of your use cases are a bit limited in what you can actually do at the Edge, but you can take advantage of the Edge to do whatever it is you can do because it's going to be faster than sending that request all the way over to the data center that the serverless functions or server are actually hosted in. So you can take advantage of the Edge for speed, but there are some limitations from a code perspective on what you can actually do. Amy Dutton: This is fascinating. I mean, it's obvious that I have three young children, but this sounds like, is it Finding Nemo and there on the edge of there reef, looking out on the open blue ocean. That's what's in my head. James Q Quick: I love it. We should have some sort of Finding Nemo reference to, for serverless or some sort of graphic, maybe. Amy Dutton: A sticker. We can add that to our- James Q Quick: We need stickers. A sticker. We need stickers. Did I say this on the podcast or- Amy Dutton: You have not. James Q Quick: Just before, but I just ordered a bunch of stickers. So I'll have them not for Remix combo, but I'll have them at Render and I'll keep them with me wherever I go from then on. So these are learn, about [inaudible 00:47:49] stickers and Compressed.fm stickers. So if you see me in person, I'll just kind of throw them in my backpack and keep them with me everywhere I go. Amy Dutton: So I guess those are more acceptable than business cards. James Q Quick: Much more exciting than business cards. I can tell you that much. Amy Dutton: What if I made a business card that is a sticker, how would that go? James Q Quick: Business card that is a... It's an interesting idea. Actually. Have you seen the... They have like credit card looking things that it's like NSC, so you bump to their phone and it gives them your business card. You're like virtual business card or whatever. Some things exist like that. I haven't thought about. That would actually be such a good idea for me to just have a QR code. Even if it just links to my website, just print out the QR code on a sticker on my laptop and be like, here, come find me. Amy Dutton: So the next section of the podcast is where we do grab bag questions. And this is where we take questions from friends and strangers alike on the internet. And so the first question that we have is from Taylor and he asks, is it a requirement of serverless cloud functions that they always shut down when complete is a single serverless function with a router and it's still serverless, how can we decrease ambiguity between the capital S framework and the lowercase S concept? Just say capital S or capitals framework. James Q Quick: Capital S I'll explain in a second. Amy Dutton: Never heard of that. Oh, serverless. Yeah. James Q Quick: So there's the general concept of serverless and there's the serverless framework I think is what he's referring to. Amy Dutton: Oh, fantastic. James Q Quick: Yeah. This is a great set of questions. Taylor, so thank you for throwing these in there on Twitter. So the first one was really interesting. Is it a requirement of serverless/cloud functions that they always shut down when complete? So you'll also hear, I mentioned serverless functions. You'll also hear cloud functions is another definition. And this is where I've kind of delineated the idea of serverless in a two big categories, a much more broad category of serverless, meaning just specifically, you're not having to manage stuff yourself. And then there's this idea of serverless functions, which gets down to some more specific stuff. So again, the question is it a requirement of serverless slash cloud functions that they always shut down when complete the first definition that I just gave where you serverless in the perspective of, I don't have to manage a server, does not necessarily have any implications of that server doesn't run when you don't need it. Now it may, but it doesn't necessarily mean that depending on where you kind of draw the line at your definition. So if you just stay really high level and say, serverless means I don't have to manage the server. There are hosts that you can use that you can get a VM a virtual machine of some sort to run something on and that may or may not actually stop running at any point. But we also heard an example earlier of things like Heroku. So Heroku will actually stop running your service if it's not used within 30 minutes. So it will shut it down. Then you'll have that cold start to get it back up on the next request. And then if we look at serverless functions specifically, or cloud functions, there is a much more specific implication of those that they do respect the idea of pay for what you use scale up scale down and not run when you don't need them. So that one does tie more specifically to the idea of shutting down when complete and when not being used. This is a fun one is a single serverless function with a router in it still serverless. So what people did or have done is they would use serverless functions and inside of the serverless function, they would run an express application, which it's not meant to be. And I don't actually know how negative the implications of that are. Although I hear it's not a good thing to do. And it makes sense to me that it's not a good thing to do, because it's not made for that. I don't know exactly how bad that is from a performance perspective or whatever. Would that still be considered serverless? I guess you're basically kind of hacking this serverless function, which is not meant to run all the time to run all the time. So yes, but I think the bigger answer is like, it's not what it's made to do and you could hack that, but you probably don't want to. And the last one is the difference between lowercase serverless and uppercase serverless, which is the serverless framework. Serverless framework is a specific framework around doing serverless with AWS Lamda. I've actually got their side up now and I'll give you the headline. Amy Dutton: Is it Ramda or is that right? Does it start with- James Q Quick: Lambda AWS Lambda? Amy Dutton: No, I thought there was another thing on top of it. Like there's Lambda and then there's like Ramda with them. Maybe I just- James Q Quick: There might be, but not that- Amy Dutton: Maybe I'm making that up. James Q Quick: Not that I know of, but it may very well be a thing. I just don't know. She's looking it up now. All right. While you're looking that up. So serverless.com is the serverless framework and it advertises to be the all in one development and monitoring of auto scaling apps on AWS Lambda. So it's a framework that sits on top of AWS Lambda to in theory, make working with AWS Lambdas much easier. So it's a specific framework instead of a general concept, which is lowercase. Did you find your Ramda? Amy Dutton: Yeah. Ramda. Not making sense. James Q Quick: Yeah. What is it? Amy Dutton: Let me Google what Ramda is. So Ramda, I think is a set of functions that you have access to. James Q Quick: Sounds legit to me. Amy Dutton: But I don't know if it's like Lambda functions running on AWS that you have... James Q Quick: From what I can tell, I don't think this actually has anything to do with Lambda functions. Amy Dutton: Oh no, it doesn't. James Q Quick: I think it's a functional library for JavaScript programmers. So it's- Amy Dutton: Got it. James Q Quick: Trying to use JavaScript in a functional way, like functional programming way. Amy Dutton: Got it. James Q Quick: Instead of serverless functions. Amy Dutton: That's interesting that you have Ramda and Lambda and they rhyme and they're not related. James Q Quick: Well, it goes back to the idea that how do you come up with a new JavaScript framework? You just choose a random word and add JS on the end. And we also have, I had a typo in my blog post recently that was Netlify. It was supposed to be Netlify or no, it was supposed to be Netflix. And I said Netlify instead, but we also have Next.js, Next.js and there's one more nest, next and nucks.js. So yeah, it's not a huge surprise that there's overlap in terminology and the development ecosystem. Amy Dutton: I was talking to Henry about those frameworks and he goes, "I'm sorry, what? You just said the same word three times." James Q Quick: Right. Yep. Amy Dutton: Thanks for clearing that up with Ramda. I'm glad that cleared a few things up. So the next question that we have is also from Taylor was a separate tweet, but he asks, does serverless just mean I the developer don't manage the server or if so is a Lambda that runs a handwritten Docker container serverless? And then he was just saying, these are obviously questions just about semantics. James Q Quick: Yeah, I think we've talked about some of that. And I think it does come down to semantics and I don't have the textbook definition of these, mainly it goes back to the question of running in Express server inside of a serverless function. So I think it does come down to semantics and preference, but I think the important thing there is just to clarify whatever definition you're going with, make sure that that's clear with whoever you're talking to, because it doesn't really matter which definition you go with as long as it means to everyone else, what you think it means to you and you're on the same page. So yeah, there's a lot of opportunity for confusion around semantics with that stuff. Amy Dutton: Well, what's interesting is I wouldn't necessarily host a WordPress site, but I wouldn't call that serverless. James Q Quick: Yeah, I agree. But that's where I've seen some people kind of mention, well, the idea of Render right in the last episode, go check it out. You talked about deploying Docker containers to Render. Do you consider that to be serverless? Did you ever think of serverless in that context? Amy Dutton: It's interesting. Well, so Redwood correct me if I'm wrong ,is just running serverless functions right? On the back end. James Q Quick: I think Redwood is running. I think they have the ability to export to both a full Node server and more regular serverless functions, I believe. They haven't depending on where you're hosting. So actually yours, when you export to a Docker container, you're probably running a full Node server on that Docker container. Amy Dutton: Interesting. This does get a little hairy. James Q Quick: Again, there's like a million different intricacies where you try to define these things and it's like kind of impossible unless you just choose what your definition is and then run with it. So yeah. I don't know. Yeah. It's a hard one to be quite honest. So that's why I've kind of run with these two high level ones. Serverless means I don't have to worry about the server itself. Serverless functions are more specific and have more specific implications around them. Amy Dutton: So the next question that we have is from the Tech-Goose on Twitter and they ask, I still struggle with code structure. What tips would you give someone to structure their projects? I can answer this one, I think, or at least give my take on it. So some of it will depend on the framework that you're using because you'll have in a lot of cases, patterns that are already established. So with Next.js, one of the patterns that I'll use is within the pages directory, that's where you establish basically your routes uses file based routing, which means if I create a file called about dot JS in my pages directory, then automatically I have access to whatever my URL is slash about. So that's nice that you have that page and that routing system out of the box. But what I'll do is I'll use that particular file just to make all of my queries and calls to the database. And then I have another folder that is called modules. And inside that modules folder, I have a folder specifically just for about page while I have any component specific to that about page that I've created. So when you're working with a larger project that keeps everything nice and compartmentalized does start to get a little big and hairy. If it's a small project, it's a little bit overkill, but anyways, that structure's worked well for me, but that's just specific to Next.js. If you were running Redwood, which we were just talking about, you can use their generators and they'll actually generate that folder structure for you or Remix has this idea of nested routes. And so how you structure those projects are going to be a little bit different. So I think the most important thing when you're trying to figure out what's best is consistency, and that you're able to decide as a team, how you want to organize your project. James Q Quick: A 100%. That's exactly what I was going to say. There's all these frameworks that have this stuff kind of built in and following their best practices and tinkering around with different frameworks to see which one you resonate with, because you notice they can be fairly different on how they do things from one to another. So I think the more experience you have with different options, the more you can be more opinionated for what you think works for you. Amy Dutton: And I mean, as you experiment, you'll figure out what your preferences are and what you like and what you don't like. So for example, the structure that I just mentioned for a Next.js project, it felt like overkill for the longest time. But then when I started working on projects where I had hundreds of components was like, how do I even find what I need? And so creating that extra layer of modules to say, I'm going to group all of my about page components together. I'm going to group all my homepage components together really helped add that additional structure that certain projects have needed. James Q Quick: Love it. Amy Dutton: Sweet. So the last section of the podcast, we call it Picks and Plugs. And this is where we pick something that we like and plug something generally that we've worked on. James, do you have any picks and plugs for us? James Q Quick: I do. I am excited about a TV show that I'm going to share. It's called The Lincoln Lawyer and there was- Amy Dutton: I think I've seen- James Q Quick: Matthew McConaughey movie. Kate: Yes, that's what I was going to ask. James Q Quick: 2012 or so. And I've seen that movie, but it's been so long. I don't remember anything about the movie at all to be quite honest, but I think, I can't remember if it was Jess and I just kind of put it on one day and hit really good, like it's only one season. There will be a second season, but the full first season is on Netflix and it's just one of the most well made TV shows I think that I've watched in a while. It has a little bit of everything in it. There's a lot of kind of legal and lawyer stuff. They spend a lot of decent amount of time in the courtroom and that's really interesting, but it's just flat out really good. So I highly recommend, I recommend it's not that long. So it won't take you that long to watch the first season and then maybe you'll be waiting for the second season with me. Amy Dutton: Sweet adding it to my list. James Q Quick: Nice. And I guess I'll go YouTube. I'm probably going to be relatively light on YouTube the next couple of weeks during next, maybe a couple of months during travel, trying to work on everything's Spelt course. So it'll be a little bit light, but go and check out. YouTube also have some videos coming up there @Jamesqquick. Amy, what about you? Amy Dutton: Yeah. So I'm going to pick the Magic Trackpad 2. I actually just upgraded to the Magic Trackpad 2. And the reason that I got it was because it does not require batteries and I was using double AA batteries on the other one. But the other thing that's really nice is, I don't know if you know this, but you can automatically pair a keyboard and a mouse just by plugging in the lightning cable. So it makes it really easy if you have two computers, which I do, that I'm constantly trying to go between. If I wanted cords, I could leave my keyboard and my trackpad plugged into my COW digit and then just swap which computer my COW digit is plugged into and everything just works. So it's nice being able to have a single keyboard and mouse and work for everything and the fact that I'm not using batteries and it's rechargeable is pretty great too. And then for my plug, I'm going to plug my YouTube channel because I have promised that I'm going to have a YouTube video up. So after months of silence, we're coming back, but I promise that it's going up since I'm committing to it, I'm going to advertise it as well, but it is converting the audio player that I've created into type script, which is pretty cool, because it also catches a few bugs that went undetected. So again, a benefit of type script. James Q Quick: All right, that's going to wrap it up for this episode. If you enjoyed it, make sure to leave us a rating and review in your podcaster of choice to help other people find the podcast as well. In the meantime, that's all we got.