More on Severless - Databases × Files × Secrets × Auth × More!

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Tolinski

and Wes Bos. Are you ready for your 2nd course? This is CIT Hacks, the podcast with the tastiest web development treats out there. Today, we've got our sort of 2nd show, which is continuing the serverless show that we did. So 2 episodes ago or 4 if you count the hasty treats, we did a intro to what serverless is. And today, we're gonna continue on that, talk about databases, files, secrets off, and we've also got a couple little updates since we last aired the last serverless one. We've had a lot of awesome feedback from you guys who listen to it and, a couple things myself.

We are sponsored by Sanity and FreshBooks.

Sanity is a structured content CMS, and FreshBooks is cloud accounting.

We'll talk about them partway through the episode. With me today, mister Scott Tolinski. How are you doing today, Scott? Hey.

Tired, man. Brooklyn's got that kinda, like, sickness where she can't breathe. And, you know, when a little baby when a little baby, can't breathe, they are up all night very upset, and we gotta do the the nose Frida thing. Nose Frida? Yeah. Nose Frida. The nose Frida is the most disgusting thing in the world, but it's so worth your sleep. I I have to be the helper. Like, I have to hold hold the baby while while Courtney does the Node for it. It grosses me out that much that I can't do it. We need to explain what the nose free JS. So the nose free JS,

like a little tube on this, like like almost looks like a pen. And you put the pen in the kid's nose, and you suck their brains out. You suck their it really feels like you're sucking their brains out. Oh, yeah. And it they're just like and then because the the kids can't blow their Node. Oh. So they have to have the snot sucked out of them. And it's funny that, like, when I was a kid, we had just this little, like, disgusting little bulb that you're, like Yeah. Bring in. Like, how does that thing get clean? The nose free does Oh, yeah. You just throw it in the dishwasher.

Yeah. And,

it's it's, yeah, it's helpful. So sick pick. Oh my god. Sick pick. Yeah. The girl's so gross. But, yeah, because of that, we we are both, Courtney and I are are definitely the the Walking Dead today. We are very zombie like, and,

that's, yeah, that's where I'm at. I don't know where you're at. Yeah. Yeah. We our our little Bos, Kit, just popped 2 teeth, and he, like, slept through the night for last 2 nights. So I went to the gym this morning and feeling feeling like I'm sorry for you, but I'm feeling on top of the world by having 2 good sleeps.

So ready ready to get into it. So a couple little updates from the last show is, first, I tried Cloudflare Workers. I I noticed I noted how it kinda what it Wes. And the last one, I said, like, hi. I I have this problem maybe you could solve. So Cloudflare Workers is a serverless platform, meaning that you can write little serverless scripts for it. But the way that they deploy it is they're they're kind of in an interesting situation where because Cloudflare controls your DNS and is actually sort of someone in the middle, you can actually intercept requests much like a service worker in JavaScript.

And the idea with Cloudflare Workers is that you can intercept these every single request to a server or specific Wes ESLint .js or CSS files.

And then when that request comes in, you can either return your own Wes, or you can just pass it through much like a like a fetch request would work in, like, a service worker. Like, you could serve it up from the cache. So the problem I had was I u I've been using this the screenshot app, CloudApp, for, like, 11 or 12 years, and I have something like, I don't know, like 20,000 screenshots on it or something like that. And I've I've used every single markdown file I've ever written, every single thing I've ever done. I've used CloudApp to host my screenshots, and then I just paste the URL, and I write forward slash content dot PNG or forward slash content dot JPEG or just forward slash content. And that will serve up the raw JPEG or PNG or whatever, not the, like, the silly little thing. And CloudApp just updated their entire thing, and they just, like, removed that entire feature, which I did a quick search on GitHub.

I have 14 a half 1000 short links on GitHub.

Wow. And I was like, okay.

Thanks for telling me, first of all. Oh. I got, like, so many emails. So I was like like, how do I fix this? Do I do I have to download my entire archive and then build my own server that matches those existing URLs? Because it's a it's my own domain name. Mhmm. I pay extra for that, but, they control the server, so I can't just add custom functionality. So I'm like, I'm gonna have and I can't just sign up for another service because these URLs are are specifically the IDs of them are generated by CloudApp.

So I was like, I'm gonna have to, like, build my own thing. I don't feel like doing this. And, like, I like it. I like CloudApp other than the fact that they just screwed me on this. These are the problems that we have as developers. This is such a classic developer problem. I feel like I face stuff like this all the time where I'm just like, shoot.

What is the what's the answer? Yeah. What is the answer? So the answer was a Cloudflare worker, meaning that. So what I did is I have my domain name, Wes, and I have cloud app, which is my my, screenshot thing.

And what you can do is you can sort of jump in the middle of that, and you can write a worker.

And what I did with the worker is I just intercepted every Wes, and I said, if this request matches the URL of forward slash content or forward slash content dot PNG, then scrape the page, find the actual raw PNG or whatever, and serve that up. Otherwise, just pass that through to to CloudApp.

And I was like, this is perfect because, like, I'm able to add code to a server that it don't exist. It's obviously, it's not doing that, but I'm able to sort of jump in the middle. And and that's huge because I wouldn't be able to do that with any other someone told me that Akamai Edge does it as Wes. A comp is that how you say it? Wes

Akamai.

So okay.

This looks like a Japanese word to me even though they're based out of refer to you on this. Massachusetts. If it is a Japanese word, then it is Akamai.

Akamai.

Akamai.

Anyways, they apparently, they have a serverless product as well, which is called Akamai Edge.

Akamai? Yeah. It's kind of the the same idea. There's, oh, there's a lot more to Cloudflare Workers and that you can cash stuff and serve up the cash if you want it, and you can have control over that. And one more thing, somebody someone just messaged me, and I I might even wanna do a show on this, he said. I'm not gonna say who it is because I'm not sure. He didn't give me permission to say his name, but said, hey, Wes. Just listen to Syntax Node on serverless. Not sure if it's an episode idea or not, but if you wanna dive into Cloudflare service workers, I he means Cloudflare workers.

I'm leading an invisible infrastructure migration right now from a legacy WordPress setup to a new Storyblock Netlify setup.

So we're using Cloudflare's workers to basically stitch together the headers, the menus, and footers from the old WordPress site while we move to our new Netlify pages, but serving the page back as if it was part of a normal domain. This means we can migrate from the old to the new slowly without massively disrupting the new SEO or doing a lengthy cost rebuild. I was like, oh my gosh. That's that's genius. So Mhmm. The idea is that you you just pull in the entire website with a CloudFlare Worker and render it out. And then piece by piece, you can, on the fly, replace little bits of that by, I'm assuming they're running their Netlify website on another domain name, and then they just pull in the pieces from the Netlify domain, stitch it into the existing WordPress, and, eventually, there will be no more parts of WordPress left. Wow. And then they can just turn it off, and and they can do it. And I thought that is that's a genius way to to use this sort of thing Embalers. Where when someone makes a request, you can stitch the bits together.

Stitching bits. That's, yeah, I that's man, that's really cool. Yeah. Mal. Yeah. I'm really interested. Like, this stuff is all sort of blowing my mind. So I'm mentioned that, we we need to do more on Cloudflare, so I added a card into our potential hasty treats that just JS Scott asks Wes questions about Cloudflare. Because I don't I I have a Cloudflare account. I've used it in the past, but I'm not using it currently. And I have a lot of questions about it, so, I think that'd make a good episode.

Yeah. Big fan of Cloudflare over here. I just, I don't use any of their paid stuff.

I just use all their free stuff. Money. I don't give them any money, but I all the free stuff that they give you is is awesome. We also got another note, and this is a great episode. Too bad,

only too bad you didn't cover Stitch, the serverless platform from MongoDB.

I had never heard of Stitch. Node it seems like everybody and, everybody is coming out with a serverless platform.

This one seems to be really kind of interesting. So this is comes to you from mongodb, mongodb.comforward/cloudforward/stitch.

This is the very first time I'd ever heard of it. I popped it open. It looked pretty cool. Build better apps faster with MongoDB Stitch services.

So, basically, allows developers to run simple JavaScript functions in the platform, making it easy to implement application logic securely integrate CloudServe. So it seems like, it's just like MongoDB saying, hey. If you're gonna query a MongoDB database, well, maybe you should just consider using our serverless function so you don't to have your own function. Now I thought this is really interesting too that they highlight GraphQL and empowers developers to quickly build apps with GraphQL, the groundbreaking API query, blah blah blah. And I have not really dove into this beyond a surface level, but I thought it was really fascinating considering I do use MongoDB. My database is hosted at Mongo Atlas, and, I think it'd be pretty cool to potentially check out some of this stuff here. The pricing seems pretty neat. I see what this is.

Obviously, you have your database on MongoDB. Yep. And then they will also give you serverless functions. Yep. And they'll also give you GraphQL QL API Yep. That sits on top very much like Prisma or Hasura, I'm assuming. I haven't tried it. And then they give you auth level as Wes. And then the triggers that seems like webhooks. Yeah. When some data changes and you need to do something, when that data changes, send an email. Somebody logged ESLint to your account or someone reset your password. You could send the email. Kinda cool. Kinda cool. Yeah. I wonder if they actually tried to sponsor our podcast. I got an email from them last week. Yeah. We're sold out, but maybe this is why because it actually looks pretty cool. It looks super cool. To try this out. Yeah. And they have a,

in the docs, they have a tutorial section where they teach you how to build a blog or build a to do app. You know, a classic to do. We Scott build a to do app. We got some need to dos to do.

We gotta build those to do apps, but I'm gonna try one of these and, just see how it goes. Maybe I'll do it live. I've been doing that recently where Wes a new yeah, Scott Tries on YouTube. Yeah. That's what I'm saying. Like, if I'm gonna try these things anyways or do these things anyways, I might as well just put on the camera and talk through it. For those of you who don't know, I've been doing this Scott Try series on YouTube Wes I've been trying different services like Begin and Hasura and stuff.

And, for the most part, it's really opened my mind. And some of these services specifically, like Hasura did something a little bit different than what I thought it did. So it's, I'm definitely getting my brain in that space for what this stuff can actually be. One more thing real quick is we mentioned

FAAS, which is functions as a service. It's like the open source version of running a serverless.

And I was like, well, like like, how would you host this yourself? But we discovered that you have to run Kubernetes. So DigitalOcean has Kubernetes, which Kubernetes will, scale up and down your servers as you need them. So I'm assuming that if you wanted to host your own, you could go for DigitalOcean's Kubernetes product and then run this Bos functions as a service on it, and that would then scale your servers up and down as you you need the the resources.

Kubernetes scares me. There was that, Hitler tries Kubernetes on, you know, the whole the that Hitler tries whatever or Hitler Yeah. Hitler's meme from the 2000.

He did 1 on Kubernetes, and it's it's actually hilarious. And it somebody said this is probably the best tutorial on Kubernetes that exists because he'll be like, did you did you install this? Did you do this? Did you do this? So give that a look if you haven't. Oh, man. Alright.

Let's move into today's show.

Yeah. Let's ESLint the meet. Entire show of just updates.

That's thanks for tuning in. Now now we're gonna actually move into to the next one. So we have a couple different topics here. We'll start with secret management.

Secrets are things like passwords, API keys, things that you don't want in your code because, generally, you should not put sensitive things like that in your database. Yeah. Generally. Generally. So, like, a URL string to your database, something like that. And if you need to connect to a database and you need the URL, username, the password, or anything like that, that data needs to be put as secrets, which is just basically process dotenv Scott something.

And there's all kinds of neat ways to to go about it. Some of these frameworks we talked about earlier have, an ICUI for it.

Some have a CLI. Some will, ingest a dotenv file.

That's how I personally how do you manage your secrets? I use a dotenv file.

Yeah. It's I I use since I'm on Meteor, Meteor has what's called a settings dot JSON file, which basically just, writes ENV files. Yep. And so it it you can have the cool thing about settings is because Meteor, you can write they're not necessarily secrets if they're on the client, but you can write your your public variables that need to be constants or whatever. And then you can write your private ones that are only server side, and it just handles it all super nice.

That's cool. Some of them have a really Node, like, dev begin specifically has a dev staging production interface. Mhmm. So I I don't really like managing secrets via the command line.

I much rather either put it in a dotenv file or just go straight into the UI of whatever hosting service you're using. Mhmm. And a lot of hosts will have have that for you. And then it gets a little trickier when you have multiple staging environments. You've got, like, a development, a production, and a a staging environment.

Yeah. Yeah. And I I I know they frequently say not to have several dotenv files and to just have all of your your code do that. In in Meteor, it's a little bit easier than that because the settings dot JSON, and I don't have to have separate ENV files.

Yeah. But is that how how do you handle the environments per

Yeah.

Usually, what I like to do is just at Node point, you have to log in to wherever you're hosting your thing and set them.

So you you set them in the UI or the yeah. You set them in the UI or or log in to the box and and paste them in.

That's, yeah, that's that's generally how I do it there, and then I I maintain, like, a a local file for my local development. Word.

Next up, we have vendor lock in. So one thing to really think about is, am I going to be able to move this away from either the hosting provider or I guess there's 2 types of vendor lock in here. You can you can be locked into a lower level provider like AWS or MongoDB or or something like that. Like, even, like, if you think about using a database, you can just use Mongoose, and now you're locked into using Mongoose as a database.

Or you can use a higher level SQL package that will have the ability to you could use any database you want under the hood, and the code that you write is exactly the same.

That's called a ORM, which stands for object relational mapping.

Object I've never actually looked that up myself. I always just know that ORM puts a layer between the databases, API, and the actual API code that you write. Yeah. So that's that's, like, sort of one type of lock in. And then the other type of lock in JS, like, a more of a framework lock in, meaning that if you write code to a specific framework, can I take that framework and host it anywhere I want, or am I am I bound to a specific host? So the questions I always ask myself is, can I take my app as is and host it on another provider? Mhmm. Can I refactor some config and run the code as is? Because I think in generally in serverless, most of this is just JavaScript code at the end of the day. But you always have to ask yourself JS, if I get, like, banned from this service, can I move this thing somewhere? Or if that service shuts or or if that service is down for an entire day, can I emergency hot swap this thing over to an entirely different piece of infrastructure and it will work, or does some secret sauce run on that hosting provider that I would then need to sort of move over and re refactor the code? You really have to think about that because,

again, like, if we often applaud these layers that make our life easier sitting in front of these things. But if those layers end up becoming, like, a real tight lock into a specific platform, that is, definitely a that maybe gives you the option to migrate off easily or or move somewhere else. Definitely something to to consider there. Yeah. Like,

Node huge lock in is just using Firebase and Node necessarily bad. I love Firebase, and I would I would certainly do a project on them. You just have to think, are they going to pull the rug out from under me in terms of tripling the costs like Google Maps did or just shutting it down, like, parse shut down at one point. Mhmm. Whereas if you did it on, like, an open source framework, then you could cert certainly just move it somewhere else. In a lot of cases, it's it's fine. You're like, I trust this company.

If we have to move off of Parse to something else, then so be it. It we'll have to cross that road when we get to it, but we're moving quickly enough right Node, so it's well worth it. Yeah. And,

I mean, we we look at Firebase, but just keep in mind that every single cert like, you think Google owns Firebase. Right? So, okay, is Google gonna shut it down? They're probably not gonna shut it down. They're not gonna shut down, like, their what is their Google app? RSS reader? Yeah. Yeah. No. I'd say, well, what is their their app one? Where it's a Google app? Goo,

Google Cloud. Google Cloud apps or Google Cloud. Their AWS. Yeah.

Yeah. Node some, you know, some combination of words with Google Cloud and apps or something. Google Cloud compute service.

Yeah. But Google is absolutely famous for shutting down their services. So, you know, there's just about a the the graveyard of dead Google services is almost larger than their active Google services. So, yeah, yeah, those are definitely things you would need to consider when thinking about that. So couple quick examples here. Obviously, I haven't gone into them all.

So Next. Js will only run the serverless part of it on Now.sh, which is Zite's hosting platform.

There is a community package being worked on right now, which will allow you to deploy your API routes, which is their serverless functions folder to AWS or something like that. So that's just something to think about JS if you if you went the Node route, you might not be able to to run that. But then again, site hosting is really good, so I don't know if I would would sweat that that much.

Begin is another one I have is so begin then kind of an interesting thing where they built this thing called architect, which is available at arcarc.codes.

So arc.codes is just a framework that will run on AWS, meaning that it's it's an open source framework, and you can deploy your app to AWS, and run serverless functions and WebSockets real time stuff. It'll it'll it'll interface with s 3 for your we'll talk about that stuff in a bit. But, like, basically, there's a bunch of different parts and serverless functions being probably the biggest part. Mhmm. And then so then if you wanna host on begin, like, you have to use architect to host on begin. Like, you have to code your way, and you have to code your app in a certain way to host on them, which is not true on sites now because sites now, you just have to they have all these different ways to host an application. And as long as it's a a serverless function in some way, then then you can host it host it with them. You don't have to really fit the structured rigid way. Whereas begin, you have to code it in the way of architect, but the upside to that is that you can then take your architect. If you didn't want to host it on begin, you could just bring it somewhere else. And the only lock in that you have there is that it only runs on AWS.

It's nice that they took the the the forethought to prevent locking in those sort of ways, you Node. Mhmm.

It's like, here here is this platform now that okay. Well, if begin, for whatever reason, is no longer there, you're not you're not screwed. You're you're, you can do it yourself.

Yeah. I I think in in most of these like, we're just mentioning this, but I don't think that this is as big of a issue that a lot of people think because they probably won't go away overnight. Right. And you are still just writing JavaScript at the end of the day all of these things.

So just rearchitecting how it's configured and how requests come in, sometimes I would think the majority of your library code would still move from one to another. Mhmm. Totally.

So let's take a quick break to talk about one of our sponsors where you can host your data and query it now with GraphQL.

And we're talking about Sanity atsanity Scott I o. I know you Scott some, hot new info for us, Wes. What's up? Yeah. They are still rolling out a whole bunch of stuff. And one thing that they just launched is GraphQL API is now out of beta.

So previously, the way or one of the ways that you can pull your data out of Sanity is with this thing called Groq, g r o q. Groq. And it's it's it's really cool language that allows you to query all of your data and filter it out and and Scott it and whatnot.

And it's awesome, but some people want, like, just a regular GraphQL API that they're they're used to. So they wrote a GraphQL API with Grok, which is really cool. So under the hood, the GraphQL resolvers are just written in Grok, and that's just been in beta for a couple months now, and it is now out of beta. So you can use either Grok or GraphQL to pull the data out of Sanity into your website, your app, your sandwich board, what into wherever you wanna display. Your sandwich board. Oh, yeah. I've been dying for that. Data.

So kind of the cool thing that they just mentioned about this is you can deploy tagged versions of your GraphQL API. So let's say you want 1 version with only your posts and authors available, You can deploy an API with a blog tag and get your own endpoint for that and another one with a podcast tag and get your podcast for that, which is pretty nifty if you want multiple GraphQL endpoints for different I know that's kinda defeats the purpose in some some cases, but, if you do want different endpoints for different pieces of data because you host a lot there, you can do that. So check it out.

Sanity/ syntax is going to get you double the free usage tier, and they also have a bunch of links to stuff you should check out as a syntax listener. Thanks so much to Sanity for sponsoring. Nice. Wes. Sanity

always putting in the work, making those improvements. Cool. Let's talk about They're hauling. Hauling. Big hauling.

Next, let's talk about sharing dependencies.

I also experienced this pain, where, basically, if you are serving just individual functions, right, you have singular functions that exist on their own.

Well, if you have all these functions, what do you do about things like dependencies, tree shaking, and your application overall? One of my solutions to this was just to have pnpm endpoint in my Next JS app. That was that was one of my solutions. I'm interested because you seem to have dug a little bit more into this than I have.

How do you how what do you do to solve this issue of having, individual package dot JSON files, in in importing and exporting amongst different serverless functions to avoid duplication.

Yeah. Well, I guess the whole idea behind serverless functions is that you have small functions that are contained. Right. And, therefore, they can run quickly and only take up the resources they need when they are running, versus a large application. The whole thing is always running, and every time you add more code or more dependencies, that application surface area then grows. Right? So the idea with serverless functions is that you have every single time you write a function, you can and we say a function, but, like, a function could do multiple things and and have its own libraries and whatnot. But, generally, each function that you have has its own package JSON, which you have to Pnpm install each of your dependencies for each, and that can be a real pnpm. Let alone almost all apps have, like, a utilities folder where like, I always have a function called format money, and that just takes in sense and ref and formats it with the dollar sign and all of that. And I more than likely need that in multiple functions and things like auth if you wanna do that in multiple. So, like, how do you share that code amongst other ones? So I asked this on Twitter, like, what is your strategy? Because there doesn't seem to be a very clear path forward, and I don't think that this is totally solved just yet. I think there's a lot of different ways to do it. So the answer that people gave me is, first, some people publish their own private module full of utils.

Yeah. So you go on, like, get a private Then you have to yeah. That's such a pain. It's such a pain because then you have to update the module. Yeah. Yeah. Let's explain how it works. So you you you have your own, like, I don't know, utils dot j JS, and you you publish that sucker to, like, a private Npm Deno, which you have to pay for. And then each of your projects, then NPM installs that module, and then you can import that. The development workflow for that is, like, what if you're working on your util library and you need it in another one? I think that's when you have to use, like, Npm link or something like that. That just seems like a big pain in the butt to me, so I didn't go down that route. Another way you can do it is you can just bundle your entire function and then tree shake aggressively, people said, meaning that you can just require everything you want, bundle it up into 1 JS file, and then TreeShake will get rid of the methods and functions and things that you didn't necessarily use. Because as it stands right now, serverless functions will bundle the entire node module, all of the read me's, all of the tests, everything that comes with it, which is mostly unnecessary in in most cases if you're just taking a sip of util from from a library.

What else? You can simply just some, serverless function providers will like, sites.

Next. Yes. We'll do this. Begin will do this. Firebase will do this. A lot of them will do this, or you can simply just require something from another file. Sometimes you need to name it something special, and that that will they will know. And then when you go to bundle it, it will just bundle that dependency in which each of them. So if I have format money in 3 of my functions, it will just bundle that format money module into each of my serverless functions for me. And then finally, Amazon has this Bos JS this idea concept called layers, which allow you to bundle up commonly used functionality, and then it will make that available to all of your modules. So if you have things that are commonly used, you can put them in a layer, and it seems to be pretty performant that way. So Interesting.

It's all kinda sucks that you have to think about that because, like, the beauty of back end was that you didn't have to worry about the size of your node modules. Right. And now you do because everything is bundled up and put into a serverless function with when you're using serverless functions. So now you Scott start thinking about that. So we'll see what that does. Luckily, a lot of my node modules, like date functions, will publish the entire library, but then they'll also publish like Lodash does this as Wes, where you can you can require, like, Lodash forward slash has or something like that, and it will just bundle that little part for you. And you should. Right. If that if that is the option, that is how you should how you should pull out those dependencies. Totally. Another big hurdle for a lot of these things is local development,

which, again, it seems like, oh, that's a problem that's been solved in the past. But now we have to worry about local development because, again, if you are having one of these serverless platforms, these functions just exist.

You kind of need something on your own end when you're testing, developing, writing code to manage and have those functions be available. So there are several of these things that do exist. I have you, I know we don't have this on our list, but have you used Netlify's version of this? I have not.

No. I haven't.

So, really, what these are are basically they're going to end up being different platforms that you can run locally.

Probably one of the the biggest ones being for Next. Js and Node Scott dev, which basically runs the Node hosting platform locally on your machine, allowing you to utilize these serverless functions just as if they were in production or something like that.

That is really the the solution for any of these is really just to have your own, utility or your own platform that goes ahead. And that that there's a we mentioned I briefly mentioned this JS Netlify dev, allowing you to run, basically, Netlify stuff locally.

They gave us a neat tour of Netlify dev, like, a year ago at Reactathon, and it really blew my mind. But I have not used it because, to be honest, most of the stuff I'm hosting on Netlify right now doesn't even use their their serverless functions at all. I I I'm curious about a lot of this stuff. I have used now.dev, and I must say, I do get a little bit, I don't wanna say confused personally, but, we have, you know, the next was it, you know, next Scott or whatever you use in Next. JS, whether the Yarn start or whatever to run Next. Js.

And a lot of times, you're hosting Next. Js apps on Node, and then, you can do dot e you can do a dotenv variables on Next JS Vercel, bundling them into the thing, or you can use the whole Node JS dot JSON stuff that they have in their Now platform. And Wes you get is you have these different branches of techniques for doing the same thing in the same platform based on where you're hosting it. And to me, that gets a little bit iffy and confusing about when to use what, where. But these platforms are really interesting. Ira Node dot or now dev, and it, it was very, very smooth, very easy to do, and for the most part, had no issues with it. Yeah. It seems

that a lot of the, like, the local dev for these things always comes after the fact. Yeah. So now has has good local dev now.

What is it? Cloudflare Workers just rolled out this thing called Wrangler, which allows you to run all of it locally. Like, yeah, it's a good it's a good name. Pnpm name. Yeah. Architect, which is behind begin, runs locally and also runs in a sandbox, which is kinda cool. I didn't even realize you could do that. That'll stop any code that's running to reaching outside to other folders or things on your computer.

It's kinda cool. So, basically, I wouldn't take a look at anything that doesn't give you Node to pnpm replication of how it's gonna run on the server. Yeah. Because sometimes if if you say, okay. Now it's locally, and now I have to, like, do this a little bit differently or, like, I've seen a lot of people just make, like, makeshift express servers that try to replicate that. That that's a pain as Wes. And and a lot I think almost all of that is gone now, which I think, again, we said 2020 is the year of serverless.

It's gonna get a lot more popular this year because the whole UI of or not the UI. The whole dev experience locally and everything is is really

good. Yeah. I'm, this was always one of the biggest sticking points for me when I first, like, heard about serverless or any of these platforms. Oh, you can run these functions now. Okay. Well, do I have to, like, go into a text editor to write them in, you know, wherever? Do I have to do some some, not like a text or like a text area? Do I have to write my functions and paste them in and then I'll try to test them? Yeah. I just remember being really frustrated by it initially, and, this you know, writing them locally is obviously what needs to happen.

And, also, what needs to happen is you need to bill your clients when you do work because, you gotta get that money, man. I mean, you you did that work. Get that money. You wanna check out FreshBooks at freshbooks.comforward/ syntax, and you just just tell them, let them know. Send them in a letter in the mail saying that you heard about it from Syntax. They would love to hear that. FreshBooks is Canadian just like our, our cohost, Les, here. Am I right?

Yep. They are. They're from Toronto, which,

very good to me. Yeah. You know that, you know that they're gonna be really nice to you. They might say sorry a lot.

Alright. Sorry. So sorry about that. So sorry about that. Okay. So, let's get into FreshBooks here. It's the all in one small business invoice and accounting solution. I know, Wes, you've used FreshBooks for a very long time, long before they sponsored this podcast, and you have been a very happy customer for that whole time. It integrates with a lot of stuff that you know and love, like Shopify, G Suite, Gusto. I'm a huge fan of Gusto. Shout out to Gusto. They're out here in Denver.

Stripe, all sorts of stuff, and they have a neat app for your phone. Do you use the app, Wes?

I use it quite a bit. Actually, my my assistant uses a lot more than me. Mhmm. So I've added her to my account. And then every couple of months, I empty out my pockets and give her these faded, crumpled receipts that are almost eligible. Yep. And she JS that to take a photo of it because if you ever get audited, I always want it to be easy. And I just want they'll say, hey. Show me a receipt for meals and expenses for this this many dollars. Like, you claim this much, show me. And having a photo attached to each of those will make it super easy to do that. So big fan of the app myself. I I use it every now and then when I'm out, and I just have a a receipt, snap a picture, throw the receipt in the garbage.

Don't have to worry about that. Perfect. Yeah. So check it out at freshbooks.comforward/ syntax, and you are going to want to sign up because, trust me, this kind of stuff is never any fun, and FreshBooks makes it totally fun. So let's get into, some more stuff. We're talking about existing applications, applications that have already been built, And how do we move stuff or how do we make things serverless? Because if you have an application, it could be difficult to move parts of it, especially if you have a lot of different things going on. With me, personally, my my API is basically one endpoint. Right? So for me, it would involve me either having to split up my GraphQL API and stitch it back together or move that whole bit.

So, yeah, let's talk a little bit about, oh, well, thought process here in moving in an application. Do you do it piece by piece all at once? What are your what are your thoughts here? My my initial impression is that you'd probably wanna do it piece by piece starting with, like, the smallest route that you have and making sure that works. The smallest route, smallest bit of functionality, get that up and running, and then piece by piece it from there.

Yeah. I think what I would do is just set would start offloading very clear stand alone pieces of the of the application.

So whether that's, image resizing or, like, reaching out to an existing API and, like, maybe you reach out to GitHub and create a repo or something like that. Just, like, look at all of the or or sending an email. That's probably the easiest one you can do. Yeah. Yeah. And then just, like, move that logic out to a serverless function, and then that will then live on another domain name. So you'll have to change your calling of that function from just running a function to making a request to the endpoint and submitting the data and getting the data back. But if if you do it properly, the returned response should be the same from a function as it is from hitting, an API endpoint. So that's kinda how I would probably approach these things. I haven't done a bigger one, but it like I read at the top of the hour, this one of moving this WordPress one around, there's there's probably a lot of kinda neat tricks we're not even thinking of here. Yeah. I moved

Vercel up to Next. Js briefly. We we talked about, I think, then the last couple episodes ago or our last episode.

And Yeah. That was me moving my API and my back end to serverless functions because I was doing it all via the API routes in Next. Js.

And I only had a few routes because it's GraphQL. You just move the endpoint, the main the main little bit there, and then you move the webhooks. And that's pretty much it for me. I didn't really have a whole lot to move. And so, if you I guess that could be considered a benefit of of GraphQL there JS if you only have pnpm endpoint. You only gotta worry about moving 1 endpoint rather than all of your different requests. Yeah. But, like, if all of your mutations have,

like, if your mutation for signing up and creating an account and sending an email and resizing the avatar and all of these things, all of those in themselves are separate packages or they don't have to be. But at a certain point, you're going to hit that serverless limit, and you're going to need to split them out into multiple. So I don't know how to get back together. It's yeah. Yeah. The what is that? Apollo Federation? Is that what that's looking to solve? Oh, I don't know. I've heard of this. Apollo

Federation. Okay. Let me see. Apollo Federation. Let me open this up. Apollo Federation implement a single data graph across multiple services.

So yeah. There you go. So that that would be the the solution there to split it across multiple services. I don't know what that looks like in terms of anything performance wise splitting. Like, where do you split your GraphQL API if you do so into different services? How unnecessarily complex does that make things? Like, is that is the benefit worth the the cost to do that? I don't know. I I don't know very much about Apollo Federation, but it looks interesting.

Yeah. Well, you could what else I'm thinking and we should probably have somebody on the show who's actually done this before. But Yeah. Totally. Wes also thinking is that, like, your resolver for your query or your mutation will all of your GraphQL API is on Node function, but the actual heavy lifting of what needs to happen in the resolver, sending an email, resizing an image, all that thing, then that can just be in a serverless function. And the resolver will simply just send the data that's coming in to the serverless function. And then you get the response and send it. You're so you're sort of just hot potato it because with the GraphQL, it's just a thin layer over top of the actual logic that needs to happen on your server. So I bet that is a good way. They should have called it the hot potato service. That seems like a Somebody wait. Is hot potato taken on what is the Npm drinking game?

Wes, Yeah.

I'm gonna go npm package hot potato allows you to pass an HTTP connection from 1 cluster worker to another. That's exactly what we want. Oh my god. I found a a domain,

hot Node Scott t o.

That's

Somebody please make this.

Hot potato is a blazing fast GraphQL

API Stitcher focused on serverless functions. Focusing on delaying actually doing anything and just giving it to somebody ESLint.

It's, like, how I how I handle email.

What else is is interesting here? Begin just rolled out a, they have their own server.

Like, most of these won't allow you just to run a Express server in them. Like, you could, but begin just rolled out a h t t p dot express method, which will allow you to hook up an old Express application or existing I shouldn't say old, existing Express application.

And then what you could do is you could slow like, you could just move it all over and then slowly move piece by piece sorta take it out.

So it'd be kinda interesting as well. Yeah. Fun. I mean, it's fun that people who clearly have experienced these problems or have experienced some of these things, like, realize what the barriers to entry could possibly be and like that and begin allowing you to to migrate your application like that just shows that they know what what the the developer pain points are there. Yeah. It's because, like, initially, when I tried this a couple years ago, I was like, this is too hard, and they have to hear stuff that that comes back. I'm like I'm like,

so you're telling me you want me to do all of this extra work for what? Mhmm. Because, like, a lot of my even my own application, I spend, like, $35 a month to host my entire application that serves up like, I've had hundreds of thousands of people do stream videos and and watch it and sign up for accounts and things like that, and I don't necessarily need I I don't feel any of the pain points that the serverless in terms of scaling necessarily means. So I would just kinda look at it and go like, Yeah. That seems like a lot of work for not much return. And and that's why like, I don't I don't think that this is the be all and end all for everything, but it definitely is, I think, also easier for front end developers just to Node a little little bit of functionality.

Just whip up a quick little script like that whole cloud app thing I did. I wrote that in the browser.

I didn't even get into their local workflow. I just started typing into the text box. How was that? It was good because they the u the experience for that is so good because they use they use Monaco, which Oh, yeah. Monaco.

Shout out. Which is just Versus Node. Yep. Which you should. I mean, at this point, if you have, like, a text editor in line, Monaco JS where it's at. Or Has to be Monaco. Code sandbox or something. And then they they have, like, a postman thing built into it as well, and they have, like, a a fake browser that allows you to view the response.

And they have Chrome DevTools baked into it as well. So they took all these things and just baked it into this amazing pie editing experience. And, like, I never use, like, a code sandbox or anything like that just because I'm like, it

it feels a bit weird. It doesn't feel like your edit. Yeah. The theme's different.

The the shortcuts are different. Code sandbox uses Monaco as well. Yeah. There Wes even a demo. The guy got Versus Node running in the browser, which blows my mind. He's just, like, shimmed all the back end stuff with Node APIs.

But this was like the 1st time I thought this is okay to write this code in the browser.

Yeah. It's going to be okay to write the code in the browser.

Alright. We're kinda running out of time here. We got a couple more things to talk about, the not not huge ones. Next one is databases. What do you do with databases?

Data, not a huge not a huge problem.

Data JS never a big problem. No. Minor thing. Well, like, you can just use any database you want. Yep. But there are a lot of services that are just coupling data with it as well, which is super cool because that's sort of where you hit that when you're writing a serverless function. Like, I just need to store something. I just need to store some little bit of data.

And now you're telling me to go set up an external database and host this thing for $5 a month. So DynamoDB is a big one from AWS, that is baked into architect slash begin.

Firebase is a perfect Yep. Use case for serverless because they have a wicked database already. Wicked. Cloudflare Workers has their own key value storage.

There's a couple other ones, and you can also just use, like, MongoDB if you already have a database set up. You just have to connect to that thing when the worker or not the worker, when the serverless function starts.

So there might be there's there's overhead in any of these things connecting to it. You're missing a hot new one.

What is it? Fauna.fauna.com.

Yeah. Fauna DB, the database built for serverless. It's like right in their headline. It's like, this is the database for serverless featuring native GraphQL.

I've heard a lot of good things about Fauna. It's on my list for the Scott Try stuff. It seems really cool. I haven't used it. A lot of people seem to really like it. But, again, when some of these things pop up, it's so hard to tell, like, what is this thing if it's just, like, some cool thing that people are hyped about for a week, or is it actually something that's going to stick around and be interesting to me? I've heard enough about Fauna and enough people talk about,

you know, how great it is that I I think I'm interested in in giving it a real shot here. Yeah. Yeah. Same with me. It says it's a serverless database that gives you ubiquitous, low latency access to app data without sacrificing data correctness and scale.

The only thing that makes sense to me there is low latency because of the whole idea of your server list function needs to connect to the database when generally the connection to your database happens when you start your app, and that that usually happens before you switch the domain name over. But in the case of this serverless functions, when you boot up a serverless function, it has to connect to the database

at that point. So, yeah, Fauna. Well, we should do an episode on Fauna. Maybe we should give it a try. I'll do a Scott Tries video on it at some point. It's on my list. Yeah. We should, like, make a tiny little app that includes, like, 2 or 3 of these things we wanna try out, and then just do a little show on it. Oh, sounds good. Yeah. Maybe we do a live show. We could do some screen sharing. Code sharing. Yeah. Might be kinda cool. Or maybe a little YouTube Little Tube It? YouTuber

thing.

Yeah. So okay. Another big issue is file storage. People often are like, I get hung up around uploading images or doing those kind of things. I personally, don't like to manage my own image server or own image folders beyond the point of hosting them somewhere. Like, I'm not gonna host it on my own server because, typically, a lot of these places, they've worked out some of these things. Specifically, for me, Cloudinary, which is more than just like an image host, they're an image, like, transformer, and you can just say, oh, here's the path to the image. Oh, oh, yeah. By by the way, choose whatever format is best for the browser to save on, KBs and stuff like that. So I always reach for Cloudinary personally, but if you don't wanna go that far into, just a service that's probably gonna cost a little bit more than something like rolling your own. You can roll your own Cloudinary like setup using Amazon and serverless functions using an s three bucket or, I'm sure, using Backblaze b 2 as well, which is also a Node store.

I I store a lot of my files on both s 3 and Backblaze b 2, but all of my images on Cloudinary.

Typically, I'm reaching for a service like this because it just makes it easy, and I don't wanna have to manage my own stuff. Not to mention if you have a serverless function, there's not really a server for you to store those images on anyways, so you're probably going to need a service or a bucket or something somewhere to put them in in the cloud.

Yeah. The thing to remember or to know about serverless is that it's ephemeral, meaning that, there is not really any memory. It will JS soon as it shuts down, it's just Node, meaning it's ephemeral. It's stateless.

You can't just store stuff on a serverless function. So if you wanna, like, upload a like, with WordPress, you upload a file. It just puts it in the WP uploads folder.

Right? And that's that's really simple.

But with the server assumption, you need to put that somewhere else that will store files back, please, be 2, like Scott said. So I think Firebase does this.

I know architect begin does this. A lot of them will it just part of the framework is handling files. And if you wanna save files or pull files off of these things, then they will be use the associated integration for that, which is pretty cool. A buddy of mine is is looking into using Firebase in serverless right now, and he does a lot of thumbnail generation. Mhmm. And he said that the what's the package that's used for resizing images? ImageMagick or Sharp. Sharp is like the yeah. Yeah. Sharp and ImageMagick are just built ESLint Firebase, which it just just works. Right? Like, imagine you didn't have to worry about

installing libraries and getting things working on Linux. It just just works with them, which is so cool. A big plus for Firebase in that regard. Big plus. Yeah. I Node. And I'm really curious because I didn't necessarily wanna when I went to Cloudinary, I was a little iffy about, like, giving all of my images to Cloudinary just because of, like, I didn't at the time, I didn't know a ton about them, but now I've obviously, I've grown to absolutely love Cloudinary.

Yeah. Well, it's it's an external service. Yeah. Right? I really looked into what would it take to, build your own Cloudinary or at least, you know, Cloudinary light using, you know, serverless functions, and it was really pretty awesome. Like, it didn't seem like it was that there's it seemed like there's a lot people doing different guides on a different approaches and totally doable.

Yeah. Yeah. Absolutely.

It's one of those things where it's a fun demo for, like, the quick resizing, and then you get into it and you realize there's so much more under the hood that needs to happen. But for simple resizing and and compression of images, you probably could kick out a serverless function in Totally. Like, even one of the cool things about cloud, there's too many cloud companies. What's the one called? Cloudflare Workers. Yeah.

The there's so many cloud companies. The Cloudflare Workers has, like, 20 demo scripts, and one of them is image resizing. I found those to be super helpful just to get just to get a base going rather than having to figure out what the docs are and and string that together.

Last 1 is auth. This is not something I've done yet, so I don't take this with a grain of Scott. But you would likely use I know a lot of people use JSON Wes Tokens for this because sessions and cookies don't work well. Sorry. I shouldn't say. I should say sessions because because the JSON Web Token can go in a cookie. That's what I do in my own course. Yeah. But, sessions are generally stored in memory or in a database. And from one to another, you can surf from 1 page, and you're still logged in in the next page, and, that's great. And with with JWT, you have to send the token along every single time either with a header or a cookie or something like that. So if you have code that is spanning multiple computers, multiple servers because they're all different serverless functions, Then JSON Web Tokens is a really good fit for something like that.

Yeah. I also haven't had duauth. It seems like a lot of these platforms that do ESLint, like, throw auth into the mix is like, oh, yeah. By the way, we also do auth. Like, you know, Hasura does auth.

We just talked about the MongoDB Stitch does auth. The same fee. Everybody does auth. Right? So at that point, you gotta wonder too, like, do you roll your own auth, or do you buy in a little bit to one of the services auth? That's also a decision you have to make about potential lock in and and what is their auth package actually doing. Is it actually locking you into anything?

Yeah. Yeah. Totally. That's lots of questions, lots of decisions to make. So that's the end of our list here. I know it's a lot to take in about serverless, but we've been meaning to do this for a while. And Scott just kicked it off when he did his little YouTube video on Begin. And then I tried it out, and I was like, okay, this is way better than it used to be many years ago. So I'm pretty excited about all of this stuff. There's so much more we haven't covered, so many more different places to host and so many different frameworks that we probably haven't even heard of yet. So we'll likely do another one coming up. And I would like to also get somebody on the show who has converted an existing, like, a large existing app just to hear. How did you do it? Like, what were the benefits? Why did you even do it? So if you know someone who has done that, not if you work for a company and you wanna pitch your own serverless function thing, but if you know someone who's who's moved a large app or website over to serverless, let us know because we'd like to have them on the show. Love that. Absolutely.

Alright.

Sick picks? Sick picks.

I'm gonna sick pick something that I got for my birthday, and that is a socket organizer.

So I've had

you Node, you know, like a socket set, like a tool. Right? Yeah. Yeah. I was you're Well, okay. Wes I was thinking, like, power power socket.

Oh, yeah. Or it could be WebSockets.

Could be socket WebSockets. Yeah. Sockets in my life. Yeah. Anyways, I'm talking about the the tool socket here. Socket TV. And I've had I'm awful with organizing my tools, and I've had a couple different Scott sets over the years when I was just, like, young, much better Node, but they all fell into this 1 big bucket of sockets. And whenever I need to find the one that I want, I can't find it. And then, like, when I'm at a garage sale and I found, like, a coffee can of sockets for a dollar this summer, it was such a good deal. And, like, the 10 mil is always the socket that you lose because that's like bikes and Yarn. They're all 10 mil.

Anyway, so I had this coffee can of sockets and I was like, I need a better way to organize them. So I went on a hunt to find out how do you organize sockets.

And what I ended up with was this sort of it looks like a game. It's basically 4 tracks, and they all have the different drive sizes on them, quarter inch, 3 eighths, and half inch.

And, you can just slot all the sockets on it, and then you can just carry this thing around wherever you go. And it's better than the stupid case that you get because it's it's much more sturdy.

It's pretty cool. It's like $30.

And I was able to take my coffee can of sockets and fill them all up. And now whenever I need to work on something, I can just grab this thing and bring it with me rather than having to dig through the coffee can of sockets.

So it's it's just called the Scott organizer.

There's tons on Amazon. I'll link to the one that I have, but do some YouTube research as well to see the ups and downs of them if you're looking at one of these. Nice.

Sockets, man. I I need some sockets in my life. To to be honest, my socket game is bad. I bought that, the glute ham developer thing. It's like this big old giant piece of gym equipment. It looks like a horse. And, yeah, it would there were so many, what are the socket bolt bolts? Just what is it? Bolts. Just a bolt. Yeah. They're just called bolts. There Wes just so many bolts. I was like, oh, boy. I have really goofed up by not having that my socket set here. I couldn't find the right ones. I ended up having to use, like, one of those, like, crappy IKEA wrenches that they give you in the packaging and then, like, this other wrench. And, like, it took me, like, 2 hours. It it probably would have been faster for me to drive to Home Depot to buy a socket set and then build it, but I was like, oh, I can't do that.

My sick week today is going to be another ebook. This one I thought was really, really interesting.

It's called The Power of Bad.

It's right up my alley in terms of, interesting books. It's a you know, I had told her I started talking to my wife about it because she's a doctor of psychology, and she's just like, yeah. I know all that stuff. But she's like, oh, okay. Well, this is all, really super fascinating. It's called how negativity affects rules, how the negativity effect rules us, and how we can rule it. Now I personally am a fairly optimistic and positive dude, so I'm Scott, like, I'm not super heavy on negativity getting into my life. But, really, this JS, like, really opened my mind to a lot of the ways that our brain works around negativity. Like, sort of the one of the the big things in that book is sort of like, oh, you could get a 1,000 comments on your YouTube video saying that it's awesome, and then you get 1 comment calling you a big dumb idiot. And, you're only going to think about the one calling you a big dumb idiot and why that is, the psychology behind it. And, it JS a been a fascinating book, and it's really opened my mind to some of the things that, negativity and, you know, nonpositive thinking can creep into your life. And, I really enjoyed it. That's a fantastic book. So, yeah, The Power of Bad. Cool. I'll have to check that one out. I got that on Amazon.

Beauty.

Shameless plugs. I'm gonna plug all my courses. Westboss.comforward/courses.

You wanna learn JavaScript,

React, Node, CSS, Grid, Flexbox, you name it. Check it out. Use coupon code syntax for $10 off. Cool, man. I'm gonna plug my latest course, which is going to be, well, forgive me. The time of recording this, I haven't necessarily landed on the the release title of this. But at the end of the day, it's going to be animating React with Framer Motion. I'm a big fan of Framer Motion as I am React Spring, but Framer Motion to me JS really just open my eyes to some really cool animation stuff you can do, and it's just so incredibly simple. I just recently built my own drag and drop package based on framer, and it's it's just endlessly simple. The syntax and what you can do with it is just immensely powerful.

So if you want to learn all types of practical animations in React, check out the latest course on animating React with Framer Motion on level up tutorials at Scott. Sign up for the year, and, you can save 25%.

Well, the the course is really neat. We are doing, like, a lot of, like, practical everything is practical. Here, we're building a Node, navigation, whatever, all the stuff that you would actually use it for in real life. So, follow along at level up tutorials.com.

Thank you. Alright. Thanks for tuning in. We will catch you on Monday. Later.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows, and don't forget to subscribe in your podcast player or drop a review if you like this show.