Serverless, Deno and TypeScript with Brian Leroux

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

Talinsky and Wes Bos.

Welcome to Syntax. This is the podcast with the tastiest web development treats out there. Today, we have rid A show, much requested show. We did a show on serverless, I think, once before. But today, we have Brian Larew on today to talk to us all about rid Serverless, and I wanna ask some questions about TypeScript and maybe Deno as well. So we'll get into that in just a second. Today, we've got 2 awesome sponsors. 1st 1 is Netlify.

2nd 1 is Sentry. We'll talk about them partway through the episode.

So with me, as always, is mister Scott Talinski. How are you doing today, Scott? Oh, I'm doing great. I'm doing fantastic. I'm actually doing very well. Despite we had kind of a rough, like, kids day this morning, but other than that, everything's going very, very good. So, Yeah. Just ready to get into it. Learned little bit about serverless. This is a huge gap in my knowledge base because I I know the the basics, but I don't know the the ins and outs, really, really completely. So

Yeah. So that's why we have Brian on here. Hello, Brian. Thanks for coming on.

Yeah. I'm stoked to be here. This is,

one of my favorite podcasts. So rid Oh, awesome. It's funny because I initially found out about you, probably 10 years ago. I was watching a j JSConf talk. You made Caesars as part of your talk. I think it was like a phone gap talk. Caesars are like this Canadian

it's like a bloody Mary, but with Oh. Oysters, rid I didn't know what this was until just now. I'm trying to figure out what Caesar's was. Oh. It it doesn't sound good,

but it is good.

So it's it's like a Bloody Mary, but with clam juice.

That but you Okay. In states. You have the chillada. Right? You can buy the premixed rid Gelada, which is, like, the Mexican, clamato, and beer mixed together.

Okay.

Yeah. It's kinda like that. But instead of a half beer, it's, Like a vodka or gin or something like that. It's it's very good. Yeah. I've been making them with, tequila lately, actually. Oh.

Yeah. It's a nice way to mix it up. Rid 2020 style Caesars.

Yep.

So do you wanna give us a a a quick rundown of What you used to do as well as, like, what you've been doing for the last couple of years?

Sure. Yeah. Like you said, I used to do, a lot of mobile stuff. I I think this might be a consequence of being Canadian.

You got brought up in the early web and there were blackberries everywhere and some of them could some of them could even talk To the web, like, they were the 1st thing that could do that, so that was, that was pretty pivotal, and it was very much into mobile, and, you know, iPhone happened, so that was kind of a big deal.

Rid Yeah. Hit like, hit the web kinda like a meteor, you know, like people were really worried at the very beginning that, native Code is gonna take over as the web, you know, a thing of the past, this mobile form factor and the experience is so much better. And and, the team that I was working with at the I'm called Nitobe.

We were very webby people, and we were like, wonder if we can embed a web browser in this thing, and sure enough, we could. And everyone said that's a terrible idea, so we knew we were onto something good because whenever people say that, it's usually something re expected. Good comes out of it, and, and yeah, that was the PhoneGap project, and later Apache Cordova, and I spent a lot of time re Thinking about embedding web browsers and building, single page apps in the mobile form factor, and and the compilation side of it was actually another big part of the problem re We were running a hosted service where you could upload code into the cloud, and it would pump out iPhone apps, but the dirty secret under the hood was that we whole bunch of Mac Minis in a beer fridge, powering that. And, Really? Yeah. For real. That's awesome. Yeah. So load balancing an early monolith with actual hardware and that journey led me down doing the cloud thing And eventually the cloud thing, I fell backwards into doing the serverless thing.

And I thought serverless, I was late to when I started doing it in around 20 rid 14/2015. I was like, obviously. This is where this is all going. And it was clear to me that the future was gonna be on demand. It was Gonna be stateless. It was, it was gonna be these fast tiny little functions that you deploy up into the cloud, and you don't think about runtime or anything like that. Helped Co author a framework called Architect, now, co founder of a startup called begin.com, where we make it Super easy to deploy these serverless applications to AWS.

30 seconds or less, and you could have a URL on the Internet. And, yeah, that's what I've been up to these days. I'm glad you mentioned begin at the very end there because I first tried out begin on a YouTube video called Scott Tries Begin. It was like my 1st 1st initial attempt at trying it, and I loved it. It was,

it was Intense to watch that video. Okay. Oh my god.

Rid I had those quirks. I don't know. Some people mad with those I made those before.

Yeah. Some people got really mad specifically when their product didn't work. Rid of I understand.

Yeah. It it happens. Right? Code happen. And, like, that doesn't mean I'm never gonna try it again. But Begin was one of the ones that I I thought was, like, just so buttoned up, in terms of, like, the little details being, like, fantastically there and and, you know, lots of little joy moments. So, re Yeah. I'm really, really pumped with all the work you're doing over there at begin.

Yeah. We have a a belief that the developer experience can really be Kinda like a consumer product experience. It doesn't have to be, a bummer to use. It can be fun, it can be mobile, ready. It can be webby, and, it can be friendly.

And and the cloud kind of isn't any of those things yet.

Rid You know, like if you Oh, yeah. Hop into the AWS console, it's it's No kidding. Meditating nightmare.

Rid. It needs a veneer that's friendly for folks to approach it and, figure out how to reason about it. And, you know, it's our belief that that audience rid Crows.

And a lot of folks want to get on AWS. They want all these superpowers, but they don't want to deal with the whole AWS.

I just wanna like, what so I do not want that. Yeah.

Alright. So for those who are new to serverless, can you give us, like, a quick rundown of, Like, what is it? What is serverless even? Like, I you hear this word serverless or Lambda or, like, spin up rid and all that. And people don't necessarily especially if someone's, like, new to programming, they've not necessarily hit the issues that serverless solves, and they're just like, I don't get why I have to code my code differently for this to to work. Yeah. That's Super important point too. So

what it is, is definitely a nebulous thing. So it's become kind of a buzzword and everyone wants to use the buzzword and It's spread out, but in I believe the serverless community would generally agree with me that serverless is more of an idea about how you Approach your application architecture than it is a collection of logos that you need to have to implement against. And the first sort of principle of it is you want to outsource Undifferentiated heavy lifting to a third party vendor.

You don't want to rack servers yourself.

And You know, what you wanna do is probably rent that compute. And if you take that rent the compute thing to its logical conclusion, you probably don't even wanna rent the metaphor of a server. You just wanna rent, like, the function execution.

You want that to be ideally on demand and stateless and fast as possible.

Re Uptime is like a thing that we pride ourselves on. But when you think about it, it's just a terrible inefficiency.

If we're pre provisioning a whole bunch of rid we have a whole bunch of servers laying around doing nothing, waiting for a spike to happen. We're paying for stuff that is not adding value.

So the on demand model is A pretty important component to this. Being stateless is a pretty important component to this. It can be, you know, any high level service. So rid I can think of Stripe as serverless for payments.

Right? You can think of Twilio as serverless for SMS.

But a lot of people can play it with functions, and I think that's fair because that's the most primitive, primitives that you can get, and the function execution ops often gets, you know, re Hoisted over to AWS Lambda.

That's the granddaddy in the space. AWS are the 1st people to sort of say, hey, we're gonna charge you by the function execution.

Mhmm. And it it all fell out from that. And those function executions are an important part of the story, but you can be serverless without any Lambda at all. You could consider, s 3 maybe the greatest granddaddy of all serverless things. Now you can put your index. Html on that thing, and it scales forever.

They're servers, but you're not running them. You don't need to think about that. And, that's like the old joke. You know, there's servers and serverless, and that's fine. I mean, some serverless folks get a little bent out of shape over that one. But There is, like, a lot of people who get fired up about the term serverless for some reason, and they're like, there's no such Like, I mean, there's there are technical reasons why, like, this is a different platform. Right? I mean, it's just so weird that people rid. Hear the word serverless and and get angry about the fact that they're I mean, just like the cloud. It's it's somebody else's server.

Who cares? Right? That there's there's rid advantages and reasons why and, like, they it don't get caught up in, I don't know, the branding of it all or whatever.

Well, we want everything to be, one answer, which would be really great. Yes. You know? Yeah. Yeah. Exactly. Unfortunately, reality intervenes, And there's lots of answers and they're changing all the time and that's complicated and scary.

And, and you know, if you know how to do something one way, then you see this new way of, rid. You know, it could be offensive to your your sensibilities. You might be incentivized to think otherwise.

Economically, there's lots of reasons to Be worried about what serverless is gonna do to the existing application architectures that are out there because it is such a big game changer.

You know, if you're rid. Part of the last generation of software developers you might be looking at, this is existential, which I don't think you should. Because there's never been a moment like that In history of compute, we tend to just pile technology up on top of technology.

And and that works, you know? Like, the story isn't Either or it's and also.

It's how can I leverage this in my new project? Or how can I bring this functionality over to Our existing legacy infrastructure, like, I have a good story for this one? We're working with a client that's got huge rails app, rid And some of it is written in .net somehow. Mhmm. And terabytes of data, they're not moving that to serverless. But they have a front end team rid that wants to build a modern front end for this thing. So they've put it behind a GraphQL proxy. And now these teams are communicating through schemas. They're able to build up, on their respective sides.

They can leverage their existing investment, and they're starting to pick off functionality 1 by 1, Moving it over to Cloud Functions. So it's, it's nice to see that we're kind of getting past this either or serverless rid Bad, and we're now seeing some more commingling of the techniques. And a lot of that's being driven by front end. Interesting.

Rid So in that, like, GraphQL proxy, so what's happening when they're moving it over is that they have, like, a bunch of serverless in the middle. If it's part of the existing app, they just pass that through to the existing app. But then they'll say, like, alright. You know what? We're gonna do, like, client dashboard or PDF generation or image resizing. And is that how it works? They just pick off, like, a piece of functionality and move them from this monolith rid to a function, like taking data, return some data.

Yeah. And it's it's interesting because the the ones you're citing are good rid Examples for, like, things that people can do now. So, you know, we used to run these crontasks that would be a server that would, you know, build PDFs or something from a database dump, and that's incredibly common. That's a perfect use for a Cloud Function because you could schedule these things, they go away, you only pay for them when they use, rid And you don't have to worry about any of that scheduling stuff.

It's probably just a copy paste of the logic. You know, you're not limited by runtime. There's No reason why you can't bring any binary you want with you using LambdaLayers. So, yeah, there's a lot of this migration stuff is starting to happen, and it's It's neat to see because running these types of older school workloads, was painful.

Yeah. A lot of work that you didn't need to do.

And, now you don't need to do that. Well, why would you?

Yeah. Yeah. Yeah. We're, it's very interesting interesting time. I do wanna go back to the whole, like, Legacy technology bit just for, like, a a one second is just just to to add on to what you're saying is just that so many of the best Flash developers that I knew are now the best JavaScript developers that I know. I mean, if you're out there hearing a lot of these things and feeling overwhelmed about not knowing them, you you you have You know, your skills will apply. And, also, what you were saying there reminds me a lot of how people are starting to use WASM in bits. Right? You're sort of offloading rid. The either higher complexity bits, the the the heavier bits, you're offloading them in chunks rather than making some sort of rid Grand migration all at once, and I think that's a a really comforting thing for a lot of people to know that it's not like picking up and moving your platform to serverless. It doesn't need to be like that or or should be like that. Well, I learned,

JavaScript from ActionScript too. So it was def definitely where, You know, like writing JavaScript 15 plus years ago was pretty out there as an activity, but writing,

building Flash apps was not. Rid A lot of, that stuff came over into ES 6. And thank god it did because it's so much of a nicer language. Yeah. Yeah. So let let's talk about bit more about, like, if somebody is working on a traditional app right now, their skill rid That will move over. Like, if you're working on a Node app, you can just write JavaScript in a serverless function. Even, like, I know an architect, there is even, like, an express re function where you can just, like, literally take your express controllers and plop them in. And there's, like, a couple of things that are you kinda rid to, like, know about about serverless functions that are different than a traditional server. Like, what are there? There's, like, there's no memory, rid Really? Because, like, if it spins down, it's gone. Right? Like, that that computer is is now doing something else.

It's completely stateless, And they do stay warm as it were, so a container will get reused under the hood, or a VM will get reused, but rid Not, for the same execution. So like a brand new, executions happen and then this is there's concurrency. So if you get hammered with 10 requests, you will probably get rid Ten separate instances of VM responding immediately, and then that scales up by default to a1000 on a on a stock Amazon account. But I know of people that have bumped that limit up to 40 or 50,000.

So it's, it's wild what we can do now. So the scale part of the questions is rid Oh, but the trade off as you mentioned is that you don't have a disk, not really, you get a 500 meg temp disk, and you can have it for 15 minutes, Which is pretty good. You can do a lot of stuff with that. Most web apps respond within a few seconds, so it should be should be plenty to do what you need to do.

Rid If you're building a web app, if you're building something that needs to do longer lived, you know, invocations, this isn't the Perfect technology for that today, but the thing I keep trying to remind people is, when we started this journey down serverless, it was 3 seconds of execution, And today, it's 15 minutes, and that number is not gonna get lower. And and the cold start is gonna continue to drop to 0.

And as there's more competitive pressure from Azure and other players, Amazon will continue to drop prices. So this,

Paradigm just keeps getting better, not worse. Yeah. Yeah. Can you tell us a little bit more about a cold start? Because that's something you hear against serverless haters. They'll say, rid I'd rather give me Kubernetes or something all day long, but the cold start kills me. Like, what is that?

Yeah. So when the Lambda function gets invoked, it has To mount itself into a virtual disk of some kind. And that mounting process, is effectively unzipping the file system. Re And if it's got a big file system, it's gonna take longer.

And the cold start is pretty much directly correlated to that mounting. And rid If you have a bigger function, it's gonna take longer to start.

So the solution is write small functions.

Keep them under 5 megs, and you will be sub rid second. Cold starting. We we typically see it begin cold starts between 70 and a 100 milliseconds now. So it's Not really an issue anymore. I mean, not a human perceptible issue if you're really trying to count those milliseconds seconds, and you're doing a real time app. This might Yeah. Might not be perfect, but it's pretty close. Yeah. So older application architectures Really didn't contend with cold start, because they were all intended to run for a long time. So if you're running a JAR file, it didn't really matter that much if it took a minute to start up.

But it matters now.

And so if you've got a kind of if you're running Java, frankly, you're gonna have a bit of a hit to that cold start, that you wouldn't see with a Node. Js or a Deno or a Python or even Ruby now is actually super fast, which is underappreciated, but a great place for for Lambda functions. Awesome.

So you mentioned, briefly about, like, languages.

What languages are and aren't suitable because so there was, like it was briefly touched on there, but I I think this can even lead into some of the talk about, Deno and in TypeScript here. So, like, if we're if we're writing serverless functions, would something like, let's say, Rust be appropriate for serverless functions?

Yeah. Sure.

So Lambda has a few ways of extending itself. And the popular easy way is layers.

And layers let you, bring anything you want to the party that can compile into a Linux run time. So Rust is in play, Go is in play, .net, Java, you name it.

All that would would be possible or is possible.

Your default is probably Node. JS.

Yeah. The Deno thing is exciting, because Ryan and Bert are well aware of the importance of cold start, and rid They and Node are going to be competing on this more and more as time goes on. Node has amazing cold start properties, and rid So this doesn't probably matter to someone who's just building sort of like a whatever web app, but if you have a huge workload, And you're doing, you know, millions of invocations.

That starts to add up and that becomes a cost center that you will pay attention to.

And so there's going to be some economic incentives to to think about this over the long run. Have you heard of this Aleph dotjs

rid Platform, I guess you could say. This just came on my radar today because, Joe I'm sorry, Joe, if I mispronounce your last name.

Rid. Or j s Joe is maybe how more people would know him on Twitter. He just tweeted about this today, and I've never seen this before. And so this library, alif.js, rid. Is basically you could think of the Deno 4, Deno, whatever, for Next. Js comparison. So you get file system routing, static site. And I'm interested in this because I rid. I don't see anything about their whole serverless API folder structure, but I know Next. Js has been pretty responsible for A lot of people using serverless functions a little bit easier in the the mainstream more recently. So I don't know if this was on your radar, but I this just popped up for me today, and I thought kind of interesting given the topic of, you know, Deno Deno versus Node. Js here.

It looks cool. And I think this is where we're gonna see a a Flooded these because Mhmm. Deno takes out the a lot of the config steps required to build something like this. Like you get SSR rid Sort of for free because it's just part of how Deno works being a TypeScript based runtime. I imagine we're going to see a lot of these types of things. And yeah, from a, From a Lambda perspective, this stuff is just, another thing that can pop out a string. You know, it could be a bash script, it could be Deno, it doesn't care.

And And that string, if it's got markup, then you'll do the right thing by you. But you don't have to now think about the routing layer the way that we used to, and you don't think the load balancing layer, and and the cost is also way, way, way, way cheaper.

I think it's something like, 10¢ per 1000000 executions.

So Yeah.

Sounds good. Yeah.

And you can spread that out across Amazon accounts. You can, enjoy a free tier of 1,000,000 executions.

And so it's just it's ridiculous how cheap it is comparatively.

Ready. Amazing. Because, like, it's true. Like, I hear all the time that even in my own courses that we go to host a Node app, and it's 5, $10 a month. And if you've got rid. Like, you can run $1.5 DigitalOcean Server and and whatnot, but that gets that gets really frustrating, especially if you just wanna, like, rid a bunch of projects. Like, I remember back in the day, you'd have a FTP folder, and I have a 100 little fun projects in there. And that that seems rid A lot harder nowadays, especially, like, you could there's a lot of free services out there that you can host them on, but who knows if that's gonna be around in in forever as well. Rid This is my backwards math on Amazon. I think some people get a bit,

shaky on them because, you know, it's a big scary company. But, they've they've got I guess the burden of proof would be on someone to say not Amazon. Like, why why would you why would you subject yourself to rid breaking changes, that you can't control from upstream or whatever reason. Like, they've been around forever. They don't break their APIs. They're only getting cheaper than the market theater.

So to me, it's easy to go there. I think as a company, I kinda understand. Like, if You're a Walmart or a retailer. Maybe you're Right. Picky about Amazon.

But but as a self interested web developer who doesn't have time for this, Like yeah. Right. Yeah. I'm just gonna jump off to Amazon every time.

That's that's a good point to sort of explain rid everything that you touch on sorta works together because you've got like, there's obviously Amazon, which is the big supplier. There's there's other ones out there, what, like Google rid Google Cloud does it. Azure does it. And that's the thing. I kinda don't believe that they do, but I'm deep in this. So they use the word serverless, but if we start measuring, rid on the criteria

that I'm thinking about about undifferentiated heavy lifting and Yeah. Not managing scale and on demand only. And, rid the other big part of this is determinism through Infra's code. A lot of the other providers just do not have these, rid Characteristics yet.

Case of Azure, they have a functions product, but you're still running instances of Kubernetes. And the functions are in a shared responsibility model. So they're all re lumped together in the same instance. In AWS land, these functions are really, completely isolated, separated things rid that can't interact with each other in any way whatsoever, and and that's all you want because you're starting from the the least privileged, most secure, most performant way to approach it. Yeah.

In GCP, I don't know. They keep shipping stuff and deprecating stuff, so I honestly don't even pay attention because I sort of feel like they're a waste of my time. Rid And that's a a harsh thing to like say, but it's, you know, they're not even in the number 2 spot. So like I only have time to really focus rid on maybe 1 and 2, and that would be AWS and Azure.

Azure, I'm excited about long run because they've got better distribution channels than AWS. Rid You got GitHub. You got NPM. You've got TypeScript. Visual Studio Code. Codespaces. So, like, that cloud's gonna be important whether we like it or not. Rid And then, you know, the US is important because they they are de facto at at the moment. Totally.

Okay. Rid So there's obviously that, and then there is architect, which is the open source framework. So instead of, re Explain, like, what Architec is, like, how you it's an open source product, and then explain how that relates to what Began is, which is your company. Right?

Yeah. So Architect is an open source, way to generate cloud formation, and in the future, hopefully we'll be an open source way to rid Generate other types of cloud inference code solutions. And so to explain what that is, CloudFormation is a document type that you can read Hand to AWS, and they will generate resources for you. And the reason you want this or the reason this is important to you is you can get the same thing every time. If If we're telling AWS I need 3 Lambda functions, you're going to always get 3 Lambda functions on the other side. And this seems like kind of contrived, but If we don't specify our infrastructure in some kind of manifest file, there's no way for us to get a deterministic result on the other side. So it's kind of like a lock file Same idea.

Except for instead of code dependencies, it's your cloud dependencies.

Okay. You want to check that in with your code, so you can tell the cloud, 'Hey, I rid You know, an API gateway, an S3 bucket. I need this particular, security rules for it. And that document is re Extremely hard to write, and very verbose, and takes a lot of insider knowledge. So architect is a high level format, that generates those documents so you can just focus on your business logic and your app concerns without having to deal with, the low level rid We don't lock you out of that.

You can still modify and read the CloudFormation. It's totally accessible to you. Rid but we just make it easier and faster to generate that and run that locally.

Begin deploys CloudFormation documents.

By default, we deploy CloudFormation documents generated by architect.

But there's nothing stopping us or in the future from deploying other kinds of CloudFormation documents. But We're keeping it on the happy path right now because we can control the local development experience, and that's a really big key for us. So there's a lot of Amazon out there, rid And we can't emulate all of that, but we can emulate the services that we kind of curate and pick. And the ones for web development in particular are interesting to me. So if you need to access like, I don't know, machine learning stuff or any other hardcore, like, analytics stuff, you can still do all that. But we make all the web app stuff really easy to do, and we make it, run all locally so that your development cadence isn't impacted by rid. Wait for a deploy to see what happens on the other side. Yeah. I think that's really been long long standing. One of the biggest gripes some people have with serverless is just rid Like, what the local dev picture looks like in in terms of, like, ease of use and and developer experience there. Because in my experience with it, it has it hasn't been always rid. Smoothest trying to test and use these functions locally on on various platforms. So it is interesting to see, that That specific aspect of it improve in various ways over time

here. Like, the the one thing I was pleased to see was it's I was just like, oh, serverless. It's just functions. Right? Like you said, people just think it's all functions. But, like, it also has assets like images, database Under the hood.

What else? WebSockets?

Scheduled functions.

Looks like a cron job kind of? Yep. Yep. Schedule functions, prod functions. Sometimes people call them.

Avented functions are another one that we're starting to see other providers realize that you need. But re Sometimes you need a background task to run for a few minutes. Like when someone signs up, maybe you wanna send an email, but it takes a minute for that process to run. And you don't wanna block the web request sending emails.

Yeah. Then you then you've just created an API for DDoSing yourself. Re So you wanna have that run-in the background somewhere and fire off an event, so that's another capability.

And Queues are another one that's underappreciated, but kind of cool. So sometimes, you need a background task, but you can't hit an API a whole bunch of times all at once. And you need to queue that up, so that, you know, you're only eating out, like, 1 at a time. So that's another one that's really important.

Database streams rid It's another cool one. So we support DynamoDB. You can write data into and out of Dynamo, but you can also subscribe a function to that. Rid Start composing your app on events in the database. Oh, that's cool. Yeah. Yeah.

Yeah. There's this sort of new world where our data is Lending in with our compute and the data too is another thing that's scaling to 0. So this is not intuitive, but like Redis popularized having a cache And having a time out on that cache, well there's a ton of good patterns for that.

And you want to persist the data, but you only want to persist it for a little bit. Rid Like, short lived tokens for session state, for reset your reset password flow. You know, you might have a token that's going to rid 5 minutes. That's super easy to do now with Dynamo.

Yeah. There's lots of lots of things that set it apart. That's for sure. So I'll take this quick moment to talk about our 1st sponsor of the day, which is Century at century.i0.

Now I actually just pushed read. A new update to level up tutorials last night, and we were watching Century pretty closely because when you do a new release, it's kinda nice to have your rid your eye on things in case you introduced any new bugs, and this happened to be a really huge update. So we just completely rewrote the account system.

Before we were using Meteor's baked in accounts, and now we're using accounts JS, which is just like a just a node based account system. Right? And it's nice because it plays well with the current account system we had. But moving your account system, very scary. Very, very scary. And We had some errors come in that kept saying invalid credentials. And, that's not the kind of thing you wanna see after moving your account system, and it turns out re The new account system just reports errors. It throws in a way that our other one did it. So when people are goofing up their password, It's throwing, and our Sentry caught that. And we were on it at the moment, and we're able to find out, oh oh, it's just people messing up their password. Rid. The site's just throwing. There's no issues.

Able to breathe this morning. So Sentry had my butt for that because I had my call stack. I could see how many instances of this was happening. I could see the users. I could see that this was in fact introduced in the build that we deployed last night, rid And it's not a bug. So thank you so much to Century for sponsoring.

I use and love you every single day. So head on over to century.i0.

Use the coupon code tasty treat, all lowercase, all one word, get 2 months for free, and you can breathe easily just like, I did this morning. So thank you. You're a big fan of TypeScript and types. Right? I think I saw a tweet from you the other day

that they were talking about bringing optional types to JavaScript. Was that you?

Yes. I might have been I might have been inciting that.

Why are types in JavaScript so awesome? What whether it be The TypeScript or, like, do you even think we're gonna get types in regular JavaScript someday? I would assume so. I mean, I don't know why we would Stop improving the language now. It's it's always been painful,

for sure. But Ruby and Python have just done this too, and I think they took a lot of inspiration from the the incremental typing that you see with TypeScript, and yeah, it makes for A better debugging experience in many ways. You catch those bugs earlier, and that's nice. And it's especially nice in a dynamic language like JavaScript.

Where TypeScript can only help us right now is at author time, which is great, you know, any help is better than no help, And I particularly like using the JS doc style,

so it's very unintrusive. I don't need a build step. I can just, annotate my functions, and I get all the help Visual Studio code. For our listeners, that's where you instead of putting the types in the, like, function and the return, you write it in a comment above the actual function. Right?

Yeah. Or you can import, typedefs. So you can, you know, write your own typedefs and then import those in the comment. That seems to be like a really nice way to work, but doesn't help me once I go to production and my code's running, live. And now this is a can of worms, but, re It would be nice to have, some degree of contract validation on function signatures at runtime.

You know, being able to Capture that data in my

submissions of forms or whatever would be really nice because we're rewriting that code all the time anyways Yeah. Sometimes. So I think I'm candidate number 1 for the the the type of developer that went from being like, oh, TypeScript is too much work for me rid. To being, I need types everywhere across the board now.

Like, our API is a GraphQL API that's fully typed. Everything is using, like, code gens to generate the types and types across the board. And I want I want types straight up now in in JavaScript, badly now that I I've I've learned rid Just how awesome they are, as a a non computer science person overall. I I I just think more developers as they Get more into TypeScript like I have. We'll see that just how beneficial it is to have that stuff, and having it on runtime would be would be sweet.

Yeah. And, like, Deno gets us a little bit closer. There's still kind of a little hidden build step in there, and they they've got some Reconciliation to do right now on the TS config side. So when Deno initially launched, it was like, hey, use TypeScript, and we'll respect your TS config. And And more than 2 people are using it at once now, and they've discovered that if they don't have the same TS config, things could be bad. Ready. So they're they're going to be moving to some kind of recommended system probably that you can opt in and out of, where everyone will hopefully have the same TS Config. And, and it's good. But, like, yeah. Once you get to runtime, there's there's just, like, slightly more I want out of this. Rid And Mhmm. And we don't get that with TypeScript yet. So, yeah, I'm assuming, especially after the whole Promise and ES modules thing, that TC 39 wants to continue to Improve the language. And Yeah.

I'm I can't imagine that there isn't more broad consensus, like, that this could be a good thing. And where this becomes problematic is what happens to TypeScript.

Yes. Right. Yeah. Because, obviously, owned by Microsoft, and, there's sort of, I don't know, interest there all around. You know, is Microsoft become the the owners of JavaScript? The the de facto JavaScript, or is this kind of happening if They're owning in control of the basics. Log this that thing. We cut to 10 years later. Microsoft script.

Yes.

So are would you say that you're you're in on on on Deno, Dino,

however however you say it? Yeah. I keep saying Deno because they were saying that, but now they're all saying Deno. I'm totally out of work. What can I do about this? So see myself. I'm like, Scott, we've been saying it wrong. We've been saying it wrong every episode that we've said it because we've said it, I am a fan.

I think, you know, more V eight based, LinuxC runtime Options are awesome.

Node is still great and my go to, like, you know, it's my right hand tool. But rid As an as a new contender, it answers a whole lot of really important questions, what how this thing could evolve, and and I think it's also driving Node to be better. So This is win all the way around.

The other kind of angle to this and again, it's just like our nature. We all want this to be like one answer, but there isn't one. You can mix and match this this stuff.

You can have a Deno function, a Ruby function, and a Python function all in the same app. That's rid And and that's cool. Like, you're allowed. And and it's maybe a good idea, because sometimes Python's better at some stuff than Ruby is, rid Or vice versa with Deno and Node. Like Deno for a front end layer is sweet.

It's got all the things that you kind of wanted to be there the whole time. It's thinking about the front end from the very beginning with a very browser y API.

Fetch is built in. Node modules are important. Export are built in. Async await is a thing.

It's not a bolt on to kind of an older way of thinking. So I can imagine just like many of the other trends that we've seen, front end is gonna drive a ton of adoption to Deno because it re paves over a bunch of these ports with Node.

Meanwhile, Node's not slowing down. They're gonna take a cue from this and improve their story. So

Yeah. And and I think projects like that Alif are going to get a long way. I mean, just make it easy. Right? Make it easy for people.

Yeah. At the end of the day, that's what we're all looking for. We wanna go home at 5, and our lives continue. And Yeah.

Ready. It looks like they're they're migrating they're not migrating, but they're building a lot of the node core APIs

right into Deno. So theoretically, you would be able to take a lot of your utility libraries to just bring them bring them in to Deno. Right? Rid Yeah. And the other angle to this, they're paying close attention to what happened with npm because they lived it. And, they're building a lot of that in as a part of a standard library for demo. So So where we would normally be reaching for NPM to, you know, bring our run time up to some kind of, development stack that we need, rid Deno's already made a lot of these choices for you. So it's got a built in linter tester. It's got the full node standard library on the way, most of the browser API, rid And then just a ton of stuff that you probably need, like, I don't know, GUIDs are built in.

Other other things that, like, For years, we're like, why is this not built into Node? And the Node philosophy was to be this lightweight, small core where you would rid pose it with user land modules, and that has come to its logical conclusion where we have a huge amount of user land that's

rid. Some of it's good. Yeah. It's good. 1 guy can take down half the applications. And some of it's mining Bitcoin on your computer. Yeah.

Rid The other angle on this, I guess, for, the Deno core is is coming out from a security standpoint. So they they want to have, versions Kind of full featured standard library, and then have really tight permissions around how it accesses the underlying operating systems that you can really finely tune the permission model.

Rid This may not seem like that big of a deal, but it's a pretty big deal. And larger applications, especially in the enterprise, security is is key. And rid If your runtime can block you from reaching out to the Internet or whatever, that's just a handy capability for isolation.

So I think we could end up seeing Node do some of that too, with time. Our sponsor today

is another company that has Some serverless offerings as well, and that is Netlify. So you probably know Netlify from being able to host your static website, rid. But they also offer we've talked about the analytics and serverless functions and all that good stuff. And they just rolled out 2 things recently, which I thought were very, very interesting, Especially if you're running like a like a Gatsby website and you do need to add some sort of functionality to it, they release background functions, which is great because rid. If you've got a serverless function, just like Brian said a couple of minutes ago, is if you have something that needs to run a little bit longer and not block the with a web request, rid Then you can go ahead and grab that. So background functions is pretty cool. And then they are in early access, I think I'm gonna ask for this myself, of rid Edge handlers, which I thought was really neat.

And what that seems to be is at the edge, you can sort of intercept the request rid and run some code at that point. So whether that's I think that would be kinda cool. With the Gatsby website, you could, you could personalize the website a little bit, at the edge by running a little bit of JavaScript. They have a whole bunch of different examples here, AB testing, aggregating API, localizing content.

Rid. Pretty nifty. I'm excited to see them. That's, like, one thing that has been becoming popular in the last, I don't know, a year or so that I've seen pop up is rid this ability to run code at the edge. So check it out. Netlify.comforward/ syntax.

Thanks so much to Netlify for sponsoring.

Do you think websites should be able to work without JavaScript?

It's a great question.

Yeah. I think that's a a worthy goal. I I don't think, I'm gonna say that's an edict or, something that always is the case. But if you're gonna start from a place, I think starting from the place That's most accessible is a good place to start.

I think it's easy to do if you start at that place. If you haven't started at that place, it's not gonna be that easy to do, and that's rid Totally okay. Yeah. That it it I remember back in the day where you would make, like, a form, send a post request

rid to the server. And then you would just add a little bit of jQuery on top to make that happen in the background, and then you would display the answer. And we've sort ofly moved we moved away from that. And you rid. You take the action off your form tags now, and you handle it entirely in JavaScript. So it's it's always interesting to me to see people who are like, no. We can still make this ready. Work without JavaScript. And that's not just for, like I'm always like, well, who's turning off JavaScript? Right? But there's a lot more use cases that that could happen where JavaScript thing fails or something like that, or you're you you duck into the subway as a JS file is downloading or something like that, or you submit the thing and you get back into data.

It's time to first bite. You know, you wanna render that, markup payload as quick as possible. It's Probably the most accessible, which, you know, that doesn't mean it has to be for screen readers. It could also just mean your keyboard on your phone works, You know, the way you would expect when you hit enter, that kind of thing. And you can absolutely code all this stuff, completely client side. I'm definitely wouldn't argue that that isn't the case. But re They am saying is you probably want to start with the progressive enhancement thing generally, because you're going to get a more accessible app out of it. But Yeah. It's not an either or. It's an and also. It's, again, something also that's easy to do with cloud functions. With any provider, you can add a post handler.

And then now you've got the easiest way to do a form, and you can build on top of that pretty trivially.

It becomes a sort of a Zellitris argument too sometimes, which I don't think it's helpful, so people be like, you have to be accessible.

And that's not helpful. Like, what you really want to do is think about, like, what is the easiest way to achieve the outcome I'm ready. For right now.

And if that is to bundle it and have it all run client side, then then by all means. But, rid There is definitely, yeah, the old PHP progressive enhancement way or just the form submit.

We can see responses come back in 70 to a 100 milliseconds.

Probably good.

Yeah. You know what I mean? It's like like, not actually that bad of an experience for an end user. And I guess if there is, like, really complicated like, I had someone the other day on Twitter who was, like, how am I supposed to build an UI like Figma from from this progressive enhancement technique? And I was like, well, why are you starting with I have to rid Figma.

Yeah. Right? Like

Start with, like, what's the easy thing I can do, and then maybe

Yeah. Yeah. Yeah. Of us are writing sign in forms, not big money. Right.

Yeah.

Yeah. But I think, you know, the the client side thing is also coming back in more modern frameworks now anyways. So Or the progressive enhancement things like Remix, from the React Router guys. Yeah. I got one of the indie licenses for that. And re Their whole thing is to render server render first and then progressive enhance at the right time. And their whole thing is to be dynamic and then use caching headers instead of rid A pre render step.

And you're seeing the same kind of thinking right now also with Svelte and SvelteKit.

So I think the pendulum is actually going to swing back. And I don't think the developer experience has to be any different in these places. It's just the tools right now aren't quite thinking this way. They're they're sort of thinking like, rid I give a function some data, and I return a DOM string.

Mhmm.

Basically, how how can I do that on both sides of the world without rid having to write write it twice? This has been the sort of, like, endless struggle. But now that we have ES modules everywhere, that struggle seems to be coming to an end. Mhmm.

Yeah. I'm I'm so excited for that. Actually, that that leads me into my my next question here is sharing code In serverless functions, can you do it? And there's a limitation at some point because you you're essentially thinking like, it's essentially bundled.

Like like you would bundle front end application. For a serverless, you would bundle, like, a couple utility functions and a couple libraries, and you have to you have to every time you use something, your your function gets bigger. Right? Yeah. So this is different depending on the provider of the deployment framework you're using. So,

like, Serverless.com and Netlify and Vercel all bundle. And that means that, you know, you have to sort of declare and know your whole file paths when that function goes up, and it's all gonna get like compiled into 1 file, which comes with trade offs. So it's good for performance to have less lookups, but it's bad for debugging when you've got one rid Wow. There's an error somewhere, and you don't know where. And so for our way of doing it by default, we, upload the whole function folder. And you can put a package JSON in that function folder, and we will obey it and install whatever stuff you have in there. And then in architect, we have this concept of a source re shared folder where you can put shared code in that and then it'll get uploaded with all of the functions so that you can share code across multiple functions it's the same And then the last knife in your boot is, layers.

So if all all these other techniques fail you, rid Lambda layers lets you, compile up your own node modules. And you can or your own binaries or even your own run time if you want. You can put that up there and then you declare, we support this in begin too. You just declare the layer ARN, and then that gets bolted onto the runtime. So if you needed, rid For some reason to write your function in PHP, you can do that. And then it'll work.

Or if you needed to, like, you know, include a different version of ImageMagick or, actually, the really popular one is puppeteer.

A lot of people use that in the Lair.

Yeah. That that's actually what I tried using in, one of mine. Yeah. That was in what was it? My Cloudflare Worker.

I was using Cloudflare Worker, and I was grabbing a website and crawling it for a image and then and then returning that image inside of the HTML.

And I couldn't I couldn't use I forget. I think it was puppeteer. I couldn't use, like, one of these really slick things, and, Also, that probably would be really slow. And then everybody was saying, like, oh, if you're using AWS, you could put that in a layer, and it'd be much easier. I will shoot you a link to a a demo doing it with begin. It's pretty easy. You just give it this public layer on, and it'll it'll add puppeteer to your function.

And, yes, all the popular things are already layerified. Right?

Pretty much. I mean, I'm maintaining one right now for the demo runtime, And it's not too bad, but just about anything else you can think of is is out there. And this dude named Michael Hart actually maintains this project, called Yumda, which lets you create Lambda layers using YUM. Yeah. So which is kinda cool. So anything you could YUM install into a Docker you can create into a lot under there.

So there's plenty of mischief you can get up to with that one.

There's so much to learn. My gosh.

It's so exciting. Yeah. Because it this stuff was pretty inaccessible before, but now it's, like, just at our fingertips.

That's also what I like so much about, like, Arc and Begin and all these other companies is that rid You mostly like, most web developers listening to this podcast probably don't have to care what Yamda is. Right? Like, rid In very, very few cases and that's beautiful because it takes the, like, having to manage a server part out of the equation or writing it. Like, the worst thing in the world is re a NGINX config file. Right? Like, all that stuff is is almost gone now.

Yeah. That's true. And I what they need to know I think what folks Just need to know that it's possible. File that one away, and then, you know, when the inevitable comes and you're like, damn, I wish Lambda could do that thing. Yeah.

We

can.

Even at one point, we had we had, like, considered rolling our own Cloudinary on Lambda, and rid Surprisingly super easy, but I just didn't have the bandwidth to do it. It's like Yeah.

Yeah. That actually is is way more accessible than I was expecting. And and I think a lot of developers will, over time, start to to learn that there's some really neat stuff out there we can be doing.

Wes, you you tried to no. You don't think you tried to do dos, you'd, like, did that image hit counter thing back in it's funny. It shows up in our logs as this one big spike. Really? Rid Yeah. It's like you you happened in February? And then it's like, oh, yeah. So what I did was, like, I was, like, playing around with begin,

and What's the database called again? I always screwed up. DynamoDB.

Dynamo. I always said Denammo last time. DynamoDB. And I was like, I wanna make something that, like, rid counts and saves it and then renders out. So what I did was, like, you just hit a URL. It increments the value in the database, renders a PNG, And then and then serves it back up. And I was like, oh, cool. Like, I I did it. I did this old school thing on new school tech, and then I, like, tweeted it out. And, obviously, people are like, well, this guy. And the people just started hammering it, like, writing because there was no, like

there was nothing there. Right into the database. Yeah. Rid Straight through. It went up to, like, I think, like, 800,000

or something like that in in, like, 20 minutes.

And, you showed me some logs of, like, it didn't even sweat. We were watching me some logs of, like it didn't even

sweat. We were watching it go down because we're like, oh, we might have to put a pit in It was fine. It's just that people got bored of of refreshing that page, so it was it was cool. But it was neat to see. Dynamo just, like, came up gracefully.

It handled the load. The that API gateway was serving it as a dynamic rendered image, And, no problem, which is

Do you know how much that cost to run?

Yes. Nothing. So, we were were, like, way within the free tier limits.

Man, it's funny that so that spike that spike shows up on your, like, company wide rid thing, and we are well within free tier limit. Oh my gosh. Yeah.

Yeah. And so part of our hack, for Begin on the free tier is we smear you all these apps across rid across a whole bunch of AWS org accounts.

And, the paid tier will put you on your own dedicated org account.

Re These apps can't access each other, they're locked out by I'm But there could be a noisy neighbor effect, like if you had the West Boss effect. You wanna avoid that, but because it's all on demand, it seems to level out quite cleanly. And whenever we see these spikes, it's just a perfect opportunity to invite someone to Hey. Maybe you wanna join our paid tier and get your own get your own isolated org account. That's totally It still works. I just went to it.

840,000 hits, and almost all of those came in 15 minutes of people writing loops.

Yeah. It's a it's a different time because this used to be a scarce resource, and we would run the server forever. And now it's commodity, and we want this thing to go away. You know, you want it to shut off at the end of the request, which is a completely different programming model. Man, there's just so many, Like, fantastic threads in this episode. I don't want, I don't want to stop

pulling on them. So, I hate to do this because this was just An incredible episode, Brian. And really thank you for for coming on because I learned a ton, and I have a a long list of things to start reading now. And I I love That that's the end result. So I'm sure, the audience is gonna be having a lot of stuff to pull out too. So thank you so much. Now is the part of the show that we talk about sick picks, where we pick things that we find to be pretty sick. Things that we like can be anything. Did you come prepared with the sick pick, Brian?

I did.

Rid I'm gonna totally self interested sick pick here, but we recently added, auto fingerprinting to begin. So if you rid Wanna try out doing an app with just pure ES modules and not have to deal with a build step? I strongly urge folks to check out our fingerprinting feature which Hopefully, by the time this airs, has documentation.

And the the TLDR is with you just write ES modules, you put them in a folder, you reference them like normal files, But we'll do all the auto, fingerprinting for you, and it'll all load sort of the way you would expect, which is, nice.

Nice. What what does fingerprinting mean?

Oh my god, sorry.

So when you, when you do a build step often you'll see the files will have like a little shaw on them, it'll be like index dash like re 286e or something. And that's a fingerprint of the contents of that file. And the reason we want to do that because when it goes out to the Internet, We can cache it forever, and then if the file changes, then we'll change the SHA which will invalidate the cache.

So it's a technique that you kind of can't opt out of, you need to do this rid with your apps. Most tools just do this for you already.

But it's a build step and it's a manual one and it's something you gotta run yourself. So if you want to just try writing rid Yes. Module straight up without having any build step in between you and that, and this is a way that you can achieve that. Cool.

That that sounds really neat. Rid I got a sick pick today.

This is a another bizarre tool that I had to buy. My kids threw a bunch of stuff down our vent.

Rid We have these, like, super old cast iron ornate vents. Like, our house is, like, 120 years old.

My kids throw stuff down all the time because there's re Huge place. And we're like, okay. We have to get this stuff out of here. Otherwise, it's gonna burn, and, like, it's a bunch of their toys that were kinda necessary.

And even a flashlight that was on got thrown down the vent.

So I I was like, alright. Well, I I couldn't take the vent off because it has, like, a 100 years of paint rid Sealing it on.

So I ordered this grabber tool, which is a bendy magnetic, rid. Has a little flashlight in it. And, basically, you just press the end, and these 4 little claws come out. And then it bends wherever you want. And re I think it's really popular in automotive. If you drop a bolt into your your engine, you need to be able to pull it out. And this thing is awesome. Like, I got all the stuff out, but, But, also, I was like I was talking to my wife. I was like, I'm glad we have this now. Like, this is definitely something I've needed in the past. And, it wasn't it was, like, I don't know, $15 or so. So not super cheap, but definitely well worth having in your tool arsenal.

Sick.

I have a a fun sick pick. Not, it's a music sick pick that I I found out about this morning, and I am very happy about this that this exists. This is an album called Been here for too long. It is 28 versions of Blink 180 two's Damn It by various artists.

Oh my gosh.

Ready. There's some some really talented artists on here, and, if if you're into, that song, this is by Blink 155, which has Just a ridiculous Bandcamp and apparently a Blink 22 focused podcast or something. I have no idea. I just found out about this because, One of my favorite artists, Jeff Rosenstock, who you might know, Wes, because he's on the same label as Pup, who I know you really enjoy. Right? No way. Pup? Is Pup the band that you like That's on side 1 dummy. I've never

publicly

declared my love for pop, but they're a good band. But I wouldn't say, like, I'm a puppet or something like that. Okay. I thought you had talked about it once on this show. That's why I said that. Either way, there, Jeff Rosenstock is one of my favorite, punk artists. He's on that same label. He's on this album, so, I'm very excited to be, having this in my rotation. Just, Yeah. So check this out. I'll have the link in the description. Blink 155.

Been here too long. Awesome. Shameless plugs. You have any other anything else you'd like to plug there, Brian?

Oh, Yeah. Cool. A bonus round. We also just, released ridged. Thing called proxy.

It lets you proxy other websites from, begin website. You declare a proxy, you can rid point it at your Heroku or whatever else, and then you can override individual routes to win. So one thing we see people doing is They'll build a GraphQL API, but they want to point to an existing app or vice versa. This is the way to do it. We just released that, like, 2 days ago. And For some reason, this has been a bad week to launch stuff, so we kinda kept the lid on it.

And,

Yeah. That's another one we're checking rid Oh, that's neat. So that that's something someone would wanna take a look at if they were trying to move over a monolith and do it piece by piece? Yeah. Exactly. Sick.

Yeah. That's a a good key for anybody to to have, like, in their platform because nobody wants to move all of their stuff over. You know? Rid Like, that's a can't usually. Right? Like, they've got an existing inertia and data, and there's just they're not gonna rewrite the database.

It's, I think it's the future of serverless is not our big rewrite. The future is gonna be these hybrid architectures for sure.

Ready. One other thing I wanted to just note is I thought this was really interesting when I first met you guys at, conference was your cofounder is is Ryan Block, who's the NGADGET NGADGET guy. So the guy who was reviewing the Motorola flip phone and all that stuff back in the day, And, like, I because, like, I grew up, like, like, reading all of his stuff, and, like, when I met him, I'm like, oh my gosh. You're my child. Yeah. Yeah. Internet tech.

Rid So he's, obviously, a developer as well? Yeah. Old school web developer as well. And, similar to me, kinda over it rid On the server side and wanted to just focus on the ease of use side. And, yeah, Ryan's probably landing twice the commits I am these days.

He's he's hacker, for sure. What a badass. Yeah. Yeah.

Cool.

I'm gonna shamelessly plug All of my courses, west boss.comforward/courses.

By the time you're listening to this, I'll probably have my advanced react course rerecorded as well, so check that on out. Use a coupon code syntax. Rid $10 off.

I'm gonna also shamelessly plug all of my courses at level up tutorials.comforward/pro.

We have a new course every single month, and, who knows? Maybe there's going to be some interesting content related to Deno on level up tutorials at some point in the future. So we'll see.

Sweet. Alright. Thank you so much again for coming on. That was awesome. You answered all of the questions that I had for you, so I appreciate that. Yeah. Yeah. Thanks for having me. I super appreciate it. That's awesome. Well,

congratulations, Scott.

And I think now you can not think about that for a while.

No. All of us in Canada are like, thank god.

Thank you, Brian. Have a good one, guys. Peace. You too. Peace.

Head on over to syntax.fm for a re 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.

Rid.