Jakson Episode #142: Cloudflare Workers with Michael Hart täydellinen litterointi

functions. Although CloudFront Functions didn't exist back then, but just this idea of manipulating things at the CDN. I think Fastly, was already a thing at that point too, but, a lot has changed though. Because I'm just writing my newsletter today and all of the serverless database offerings that are out there now, like just so many of them like constantly coming out. And then all these edge networks, all these container scaling platforms. I mean the marketplace and the ecosystem has just exploded. I mean, even from what was it, it was 2019 or whenever that episode was that you, that I had you on. So I'm curious- a couple things. So at Cloudflare now, you're working on the Workers team. So maybe we should just kind of reset here and talk about that. One, you know, why don't you tell people a little bit about yourself, and then what you're doing at Cloudflare, and then let's get into Workers and sort of how they've evolved. Michael: Yeah, sure. So, prior to this, I had a nice, six month break, prior to joining Cloudflare. I've been with Cloudflare now for, two months. And prior to that, I was VP of research engineering at Bustle Digital Group, which is a media company, all sort of on serverless. So doing lots of serverless things for them. And that was my role when I was last on on Serverless Chats. I actually should ask and I didn't ask this in our pre-show chat. Have you had anyone describe Workers on Serverless Chats yet? What Workers is? Jeremy: I don't think we have. Rebecca: You're the one, Michael. Michael: Well, okay. Well, yes, I may as well start there then, because I noticed I had a look at our transcript from episode 18. I did mention Cloudflare Workers at the time cuz I was comparing it, contrasting it, with Lambda. So for people who are familiar with AWS Lambda and similar offerings to that, those run times are running sort of a full Node.js process or similar, or a full Python process and running your code that way, serverlessly. The difference with Cloudflare Workers is it's using the V8. So Chrome's V8 technology. And it's using its isolate model. So it's JavaScript, JavaScript and WebAssembly. And it's running your code in isolates. And the advantage of that is it's very low overhead. It's much faster to spin up an isolate. And, you know, it's called an isolate because it's isolated you know, from other isolates running in the same process, but you're not spinning up an entire container or anything like that. Each time you're using the sort of technology the Chrome team has written to keep, you know, individual tabs and things like that separate and to keep to keep JavaScripts from interfering with each other, Cloudflare uses that technology in Workers to keep people's serverless code running separately. So that's sort of one big difference there. It's all JavaScript, essentially JavaScript and WebAssembly. So anything that compile to WebAssembly or JavaScript you can use, as well. But it's not the same as a container model or even Lambda, which, you know, is kind of a hybrid containery type model. So yeah, that's one big difference. The other big difference is it's an edge product, as you mentioned. And so it's running all of this at the edge. Which the advantage of that, of course, is that it's closer to the user's eyeball, as the technical terminology likes to use. So you have the code, your serverless code, running really close to the user's eyeball. So it spins up fast. The latency is really quick because it's in a data center, you know, we have like 270 data centers or more around the world. So it'll pick the closest data center and be serving the code from there. Like you say, it started off as sort of a way for Cloudflare CDN customers to augment their requests in the same way that I guess Lambda@Edge did, but it did it in a much, I think, a much sort of smoother way and a much more light touch kind of way. And, yeah, it's got plenty of use cases in that realm. I think, you know, plenty of big customers have used it. Because it essentially allows you to kind of inject anything you want into a request coming into, you know, if you've got Cloud Flare sitting in front of your entire site, you can intercept any request with a Worker and modify it. You can, a classic example, during COVID there were some big pharmacies, you know, and things were changing so quickly then. You know, there were people trying to book vaccinations and things like that. And they were constantly having to put up notifications or whatever. And it was a really easy way for them to just inject HTML into the page, right? Because you've got access to the full streaming HTML in and out from a worker. And so you can just modify it on the fly. You can, so it was really easy for them to say, add a banner to every single page on their site, regardless of what backend technology they were using. They didn't need to, you know, fudge around with, 'okay, this part of the site's using PHP, this part of the site's using Java or whatever. You can just modify it on the fly. So that's kind of where Workers started. But then, of course, if you, if you think about a world where you don't have an origin, so you don't have anything behind the Worker, the Worker itself can deliver HTML, you know, to the eyeball, to the user. So then you have a world where you can create full apps and full sites just from Workers. Jeremy: Right. And that's one of those things where, when it first started, it was very much so like manipulate the stream that that's coming back. And there's all kinds, like you said, great use cases for that. I mean, there's still great use cases for that. Especially like the ability to route things. I mean, just one of the things we used Cloudflare Workers a while back just to do basically redirects to different origins, but use the same domain name, right? So it's just totally cool that you can do that, essentially, you route a different origin and pulls the data back and it all

loads on the same URL or the same domain name. And then you just, you know, can change whatever the path is and stuff. And then route that correctly. Which is very cool to do, especially if you're combining multiple technologies, like you said. But since then, we've now sort of gotten to a point with Workers and of course there's Pages and a whole bunch of other products that Cloudflare has. But we've now kind of gotten to the point where it's like, it's an edge without an origin, like you said, right? Where you can actually now build the full apps there. So tell us a little bit more about what is the breadth of the full apps now that you can build? Like, I don't to say the limitations, but... Michael: Right. I'll try and remember all of the things. So it's come leaps and bounds. I mean, I remember when I was at Bustle and we used Workers at the time to build an originless-style system. We used it to replace our front end which was a Preact server side rendering app. So we kind of got that all running in a Worker and it was, at the time, talking to a Lambda backend that was a GraphQL server. And so that was years ago. Since, and at the time we couldn't really use it. It wasn't quite ready. I would say, you know, four odd years ago for that use case. Since then, it's sort of come leaps and bounds. It's now got a lot of those production features that you need, like logging and the ability to kind of debug this sort of stuff in production which is what we need at the time. And now it also has a whole bunch of other features like you know, stateful data sort of features. So that's one big difference. I guess, if you don't have an origin, and you're trying to create, or you're trying to return HTML, or maybe you're trying to return an API response or something like that, it's like, well, what are you doing that on the basis of? Are you talking to something on the back end? And you could at the time, and you still can. Cloudflare can talk to any HTTP compatible database. Like it could talk to DynamoDB, it could talk to anything like that. But Cloudflare, since then, has added a whole bunch of features. The first of which was Cloudflare KV, which is a key value store, essentially an eventually consistent key value store. So it kind of relieves, I guess initially if you wanted if you wanted a whole bunch of data in your Cloudflare app originally, you'd kind of have to bundle that in with your JavaScript. You know, you could have it there like a big table of data, a big object of some kind. But you would have to bundle it in with your app. And if you wanted to change it, then that would mean a redeploy which is super quick on Cloudflare Workers, but still, you know, annoying. So Workers KV came out and that opened up that use case of where you wanted data at the edge and you wanted your Workers to be able to access this data. And it's for use cases, I guess, where you're writing relatively rarely but reading heavily, and you want low latency. I guess prior to Cloudflare Pages coming along, you might have used it for a, you know, as a CMS or something like that. You know, that's a perfect use case for it. I mean, you still could use it that way actually. But perhaps Cloudflare Pages, which is the sort of Jam Stack offering might be better for that these days. But yeah. So that's Workers KV. Rebecca: So, Michael you, we have this list of things that we wanna ask you about in terms of Cloudflare and Cloudflare Workers. And the first on the list was, tell us about Workers KV and then, you know, we had a couple of questions around it, but then you went into it. It was like, 'what can you do with that?' And it's like, 'oh, he just answered that. He also just answered that. Actually, he answered that.' But we have a few other things on this list, right? We have R2, we have D1, SQLite. So maybe you could go into a couple of those and describe those as well before Durable Objects? Michael: For sure. Durable Objects. Rebecca: Durable Objects, That's right. Yeah. Michael: That's probably the next one. I'll go kind of chronologically with, like, when Cloudflare released them. So KV is great for scenarios where you're happy with eventual consistency and you want low latency. But if you want something that's strongly consistent, it's not a great option because you might write, you know, I guess if you think about it, these values are being propagated to every kind of edge node, all 270 nodes. It can, when you write a value, it can take, you know, seconds for that to update all around the world. And during that time, you're kind of, you're in this inconsistent state. So if you wanted to write a value, read a value, write a value, read a value- it's not a great solution for that. Durable Objects came out and it solved that problem. And also another problem of, kind of coordination. So it's sort of the opposite where it's a singleton data object that is living just in one place. And you can use it to coordinate things. That's one aspect, I guess, of a fully stateless system at the edge is it can be very difficult to coordinate who's talking to what. And this comes to light when you're trying to do something with web sockets, like a chat room or something like that. You kind of need a central place for those web sockets to be communicating in and out of for consistency and for coordination reasons. So Durable Objects came along and it kind of solved that problem. It's strongly consistent. And it uses a sort of object model. So you create this durable object and it lives in a particular region and all the writes go to that one object. And it's sort of single thread. It makes a lot of those difficult consistency problems quite easy because it's single threaded. So you can read to it and write from it and know that your reads and writes are consistent. And that sort of thing. The one thing that it doesn't have is that it's not distributed all around the world. It's just sort of living in the one

place. Yeah, so that's, that's essentially what Durable Objects are for. And this idea of coordination, because there's the one object. Well, you can now use that to coordinate multiple Workers trying to do a whole bunch of things. Chatroom's a perfect example. I think Cloudflare built a queuing system. You know, like, like if you want tickets to an event or something like that, and they're all gonna be released at 11:30 then, you know, your site is gonna get slammed. And you kind of wanna stick people in a queue so that first come, first serve. Durable Objects is a great way to achieve that sort of scenario. So that was Durable Objects. And that works really well. And then recently, Cloudflare announced another product called R2, which is essentially Cloudflare's S3 offering. So it's buckets. It's sort of bucket storage; storage for large objects. And it's essentially the same as S3. It's just one thing that's great about Cloudflare is, it has very low or zero egress fees. So egress is the kind of fancy term for outgoing bandwidth., right? Jeremy: Which, AWS will getcha. Yeah. Anyone who's got sort of a large S3 footprint knows, that's where a lot of your money can go. You know, especially if you've got a big site, lots of images and stuff like that. Yeah, that can really add up. So that's where R2 is coming from, is it's a way to store large objects, files, essentially. And be able to access them, you know, from Workers and from your site. And things like that. One kind of cool thing, I guess, is a good way to tie in one kind of cool thing about Workers is, you can create the way your Worker interacts with all of these extra services, so whether it's KV or Durable Objects or R2, is it creates bindings. And a binding is essentially just a way of saying, 'Hey, this Worker will want to talk to this Durable Object.' And then it becomes accessible in the Worker's environment, just as a variable. You know, you don't need to do any complicated hoops with addressing or anything like that. It's just, it's available there as an object in the JavaScript environment. And then that has some advantages, of course, behind the scenes for Cloudflare, cuz it means it knows that it can optimize certain things. Cloudflare's incredibly good at intelligently routing requests across the world. You know, that's the network stuff is what we're really good at. So if we know that this Worker is gonna be talking with this object, then obviously we can kind of ensure the shortest path to or from it. There's another, model called Service Bindings, which is a way of a Worker to essentially have a binding to another Worker. So this is a great way to split up your apps as they become bigger and bigger. And anyone, who's kind of dealt with a Lambda app at a certain stage knows this problem well, of trying to divide your app up into different parts. But maybe still from a monorepo. And Cloudflare has this concept of service bindings where you can just talk to another Worker as from a bound variable. Behind the scenes, we can do some really cool optimizations with that, where we can actually run them potentially in the same isolate. And then we pass on those cost savings to users as well. So, whereas a Lambda you'll always be in completely separate, kind of, containers. In this model, if we know that it's the same user and we can run things together and let's say one Worker is waiting on a response from another Worker, then we won't charge you for the time that you're waiting. Whereas, you know, I guess in the equivalent sort of AWS style thing, if you've got API Gateway and Lambda where you're paying for the time that API Gateway is waiting for Lambda to come back. That's one thing, actually, that I've kind of come to realize, being at Cloudflare, is that the Workers product and Cloudflare as a whole is a little bit more of a seamless experience, I would say. Which, you know, some people might view as a good thing or a bad thing. But for me, it's a little bit like if you took, I don't know, WAF and Lambda@Edge and CloudFront and API Gateway and Lambda and rolled them all into one product and then just had like different check boxes for which kind of feature you wanted. And that has, you know, big advantages when it comes to things like, I don't know, a streaming request or whatever. You just can't deal with that in Lambda. You can't. The request stops at API Gateway and then forwards to Lambda and comes back. And there are some advantages to that model, but overall, I think, especially for HTTP sort of models, it's nice to just have the smoothness of requests kind of flowing in and out of this kind of one big system. And then you can have your DDoS protection. You can have your security stuff, you can just kind of flick that on without needing to bolt on a whole other service and figure out how to connect it to your pieces. Rebecca: It's like the express train in the New York subway, you know? It doesn't have to make every stop. Michael: Yeah. yes. You're Rebecca: like, you're getting there. Jeremy: Well, Michael: Yeah, exactly. Jeremy: Something that's really Michael: You don't have to change from train to train. Yeah. Jeremy: Something that's interesting, I think, about that too, is there's always been this big thing about the two pizza team and everything's a separate microservice at AWS and so forth. And not that that is necessarily a bad model because they can work very fast in isolation and whatever. But then you always get that problem like, well, now we have to assemble these things, put them together. So you have a lot of teams talking to different teams and so forth. And I always remember, I actually it was like a Honda Accord or something like that, that I was looking at years and years and years ago. And I remember that I get in to test drive this thing. And there's the screen that has the navigation and a couple different features on the navigation screen. And then below that there

was a touchscreen that was just for the audio controls. And I'm pretty sure that there were two different teams that designed these two things, and then they're like, 'alright, now we have to fit them in the car.' They're like, 'Yeah, but this doesn't work together.' So they're literally two systems to control. It made no sense. I mean, now they're all integrated cuz somebody figured that out. But that is how I feel about a lot of the Lambda stuff. Like you can't do streaming HTTP with Lambda, right? Because you can't route that through the API gateway the same way, then you have the payload limits and you have all these other things that run into that. And then they introduce the URLs, the Lambda URLs, but then the function URLs, you don't have any control over, you know, throttling or some of these other things, right? So there's a whole bunch of stuff that I think they're trying to figure out workarounds at this point to make things work, as opposed to, I think, where Cloudflare sort of looked at it very much so as a unified system. Michael: Right. Yeah. It's just kind of extending the existing system that's there. And what's been amazing actually is to see how much dog fooding is done in Cloudflare. I'm sure this is true of many big companies, I'm sure AWS does this as well, but I'm not sure that AWS, you know, writes all their new services on Lambda,whereas Cloudflare is like using Workers for everything. Like everything now is written on Workers, which is great and an awesome sort of testament to how much we kind of believe in it. And I must admit, back in the day when it first launched, I was like, okay, this is Cloudflare Workers is really cool. But are they really gonna be putting all the effort behind this? Is this a product that I can kind of trust or is it just a toy that they're putting out there? And it's been amazing over the years to be like, 'Oh, okay, no. They're really serious about this.' It's yeah, it's really becoming a thing. And I guess internally, you know, it's just, it's such an easy way internally to create new products using Workers compared with some of the other ways that you might have to write, you know, native modules or whatever for the systems that exist. So, yeah, internally the teams have loved it as well. Jeremy: I am reading an article right now that said Cloudflare is rebuilding its CDN service on its Workers serverless API, something called Project Flame. Michael: Oh, cool. Yes. Jeremy: Don't know if you know anything about this? Michael: I do. I do. That's cool to see that it's now public. Yes. That's essentially what it is. That's it, in a nutshell. We're kind of rewriting as much of the front end side of the, I guess the entire, kind of, API gateway. The entire ,proxy front end proxy, in Project Flame. Rebecca: You could tell that Jeremy was actually reading that article right now cuz his eyes got really big as he's focusing on these words. Well, let's talk about that, then a little bit. Michael: Is that something that was announced for Cloudflare One or? Rebecca: I think so. There's a lot going on. Michael: I was gonna say, yeah, one cool thing at Cloudflare is they have so many of these innovation weeks. And a lot of these things have kind of been announced at various innovation weeks. The most recent one was the platform week where a whole bunch of things were announced. And that actually, that was something that you mentioned, Rebecca, that I haven't chatted about yet, which is D1, which is the data storage. Jeremy: Why wasn't it D2? So you had R2, D2. Is there a reason? Michael: Let's just say maybe watch this space. Jeremy: There will be a D2 eventually. We'll see what happens. Michael: I have said nothing. D1 is essentially SQLite at the edge. Strongly consistent, built on the same sort of primitives as Durable Objects. But you know, with a kind of familiar SQL interface that everyone knows. Not that everyone knows. That many people know. That there's plenty of resources out there for and I think it'll be great for, you know, there's this huge long tail of companies and, you know, eCommerce sites and things like that out there. I think that they don't need Aurora database. They don't even need an RDS database. You know, that's like, that's just too much. 50 bucks a month for the amount of data that they're storing. Now they could, of course use, use DynamoDB or Mongo DB or some sort of NoSQL offering. And I still think that's a good option, but it does for many people. And especially I think for like, consultancies out there and things like that, it means learning another data model. Whereas the advantage of SQL is it's not, you know, mySQL and Postgres aren't exactly the same, of course. But there is a very common understanding, very common similarities with the dialects of SQL that they talk and just the general concepts of a relational database. And so what D1 is, is a way for people to be able to write their sort of storage using SQL and have it available at the edge in their Workers. So it's, yeah, it's great. It should be really interesting. There are plenty of really interesting use cases. I mean, it's very early stages. It's just kind of in a private beta at the moment. But there are very interesting places that it could go once you kind of have that model. And SQLite, you know, it's just super cool. It's a very lightweight engine and it's really stood the test of time. And being used in plenty of places. It's a perfect example, I think, a perfect use case for someone who has like an Ecommerce site or something like that, where you know, they wanna store their products, they wanna store their customers, they want to look them up, they wanna do joins. They want to be able to display that data. They want to be able to write it. They don't want to think too much about stuff like eventual consistency and stuff like that. Rebecca: You talked about internal dog fooding and how impressed you were with how much

you all do that and how you build everything on Workers. And I think there's something special that happens there, right? When you are that, let's say, obsessed of doing internal dog fooding. That also means that if you're the developers, you're also improving your own experience before you're putting it out into the world, or you're understanding where the experience, where the gaps are, what fails, what feels good, what feels bad? So let's talk a little bit about the developer experience and I think you have something called, is it Wrangler? Michael: Wrangler, yeah. And how does that make it? Jeremy: Not the jeans. Rebecca: But maybe those, too. How do a great pair of fitting jeans? Um, no. How does Wrangler make it easier to build with Workers? Like how does that affect the developer experience? Michael: Yeah, I guess so Wrangler is the, sort of, the CLI experience, the console experience for building Workers. And it's sort of fast becoming, or, you could say is now the primary way to sort of quickly spin up and iterate on on a Worker's app. So I guess, a pretty good analogy in a way would be CloudFormation for those in the AWS world. You know, you can specify, it is infrastructure as a service in that sense, in that you can specify all the parts of your app that you need and then run Wrangler and it will push them all out there. And, it's where you would define, you know, some of the things I was talking about before, like the bindings where you would define whether you're binding to KV or whether you're binding to two or another, a service binding or something like that. Yeah, that's essentially what Wrangler is. It's also used for Cloudflare Pages. And internally, yeah, it's interesting. You chat about the developer experience, cuz it's interesting for me now being on that side where, you know, you have other teams essentially, that, you know, we're supporting now. And in our internal chats, people are like, 'oh, hey, how do I do this with Workers?' 'Can you let me know, how do I wanna spin this thing up?' Or I wanna spin that thing up. And it's like, 'Oh, cool. That's someone internal.' That's exactly the same sort of thing. And so, yeah, then that drives, obviously drives the developer experience and drives the way that we make tools like Wrangler better. One cool thing, actually, I was thinking about this the other day about Wrangler that I like, that I'm not sure I've seen in any other sort of infrastructure as a code style config is for Durable Objects. When you want to say, add a new durable object or modify it, maybe you wanna rename it or that sort of thing- you'll do a migration. And you declare these migrations in your Wrangler file. So you'll sort of be like, 'okay, here's version one of the Durable Object. Version two you know, is a rename action. I want you to rename from this to this, version three. And they just sort of sit there in your config file and, you know, in time, kind of, grow. But it's quite cool to then have, you know, your migrations kind of listed there with your config. You can kind of see where things have gone and where they're at currently. And it's a good way of declaratively sort of saying, this is the state of our data, this is what our schema looks like at the moment. Yeah, that was something I noticed the other day that I'd never seen before. Jeremy: So another thing about developer experience too, is also familiarity, right? When you have to learn something new, I mean, you mentioned NoSQL or data modeling and NoSQL. Like, it is just hard. I mean, there's a lot of different things you have to think about. Of course, then you're limited in terms of how you can query stuff or whatever. But just thinking about familiarity for a developer. So right now I think Cloudflare Workers support JavaScript, Rust, C++, right? Anything like you said, it can be compiled to Web Assembly or JavaScript, I think, will run. But then you also have support for like a number of third party modules. But you are not running node, right? And I think a lot of people are familiar with NPM, you know, node package manager. And they're used to running node modules in order to do a lot of things. So there's support for third party modules. You can import different things. I think you can make, you know, fetch calls and all that kind of stuff. So you can interact with APIs and other things external to your Workers. But are there certain types of modules that you can't use because of the model? Michael: Yeah. So, you hit the nail on the head there where, I think, the server side JavaScript for so many years, the answer has been node. Like actually, you know, back when node was starting there were a few options. And I guess there still kind of are, but node is by far the biggest non client, non browser implementation of JavaScript. So I guess it's kind of become the defacto, of course, in a way. And that's where NPM started. And so most NPM modules are written for node. Although now that I say that, that might not be true anymore because people have been using NPM for browser modules for a very long time, actually, you know, just as a way, cuz there was no other module system for browser modules. So they're actually probably, like even prior to Cloudflare, there probably were a whole number of browser modules that wouldn't even run in node. Cuz they were expecting browser APIs, but you were obviously expected to use them in a browser. Cloudflare users V8 as node does, but you know, that just means that the very core JavaScript run time is the same. And so things like strings or dates or all of those sorts of primitives are the same in node and Cloudflare Workers or any system using V8 really. But beyond that, once you start getting into APIs like Fetch, you mentioned, is a perfect example. That's something that, you know, goes beyond JavaScript. That's something that is then part of an API standard. And in Fetch's case, it's a web standard, you know, it kind of

replaced XML HTTP, you know, the original Ajax kind of way of fetching things. Cloudflare is built as much as possible to be compatible with web APIs, as opposed to node, which was written at a time when those things didn't really exist. So node wrote its own HTTP client, completely from scratch because there was no real HTTP client or way of making HTTP calls aside from the very clunky way that browsers did it at the time. So node kind of existed at a time when a lot of these APIs weren't being worked on in browserland. Other examples are things like streams. Streaming data, you know, and so node ended up creating its own Node.js streams, but since then there have been web standards around streams streaming data in and out. And so Cloudflare uses those. So basically Cloudflare uses the service worker model which a service worker is a thing you can write in a browser in, in your client side JavaScript. And Cloudflare is built on that kind of model. And so, as much as possible, Cloudflare is trying to support web APIs. And the sort of standard ones that if you go on Mozilla MDN, you know, those APIs. The request response, fetch, all the streaming stuff, all the crypto stuff. So, using web crypto, as opposed to, again, node.JS crypto. So that's a bit of a departure and the ecosystem is just much younger in that sense. And I should say Deno has done exactly the same thing. So when Deno came along- Deno is another another, server side JavaScript option, JavaScript/type script option, that also uses V8. Written by Ryan Dahl, the guy that created node actually. Hence the name Deno. Jeremy: If I could do it again... Michael: Yes, essentially, if I could do it again, this is how I'd do it. And it's taken a very similar path of trying to be web API standard compatible. And there are huge advantages of course, to that. There's eventually anyway, because people will know these APIs and they'll be standardized. You won't be kind of context switching between the browser and the server side. But there are some things that you just can't do in the browser that, maybe, if it was only left up to browsers, they would never implement APIs for at all. You know, a classic example might be accessing the file system or something like that, right? You don't ever wanna be able to do that from the browser, but maybe you do wanna do that from the server side. And Deno certainly has a way of doing this in its own Deno name space. So they've had to create their own API for it. But what Cloudflare and Deno and a bunch of others have been working towards is this group called the Winter CG group that was announced recently during our platform week, which stands for Web Interoperable Run Times Community Group. As I read that out, cuz I'm not gonna remember it. But this is a working group essentially to establish APIs for non browser use cases, but still to be standardized. And I guess, standardized in the same flavor as the web APIs are. So to use the same, you know, where possible, use the same stream APIs and that sort of thing,. But potentially for use cases outside of what the browser would be for. So that's really exciting because that should enable a bit more standardization in that space and getting back to the original question of so what can and what can't you run in Workers? There are definitely, you know, developers out there that come and they try and create a Worker and they pull in a node module. You know, maybe it's using nodes HTTP or nodes crypto, or nodes Fs module. And those things just aren't available in a Worker. Now, in time people have been writing, especially because node did introduce the Fetch and start supporting the Fetch API. So, in time, people have been kind of updating their NPM modules to support some of these new APIs. And I should say node is working towards trying to be as standards compatible as possible as well. It's just, obviously, it has a lot more legacy. So it's, you know, it's potentially gonna move slower than maybe what some of the others can. But there's certainly no intentional sort of competition there or anything like that. It's just node has a lot of legacy stuff. It's trying, it will also, I think, try and add as many of like web API compatible things as possible. And I think eventually you will see the entire JavaScript ecosystem using these sort of APIs, these standard APIs. As opposed to just node specific APIs. There might be, you know, I could imagine there'd still be very rare cases where they might diverge on, you know, obscure technologies and things like that. But by and large, I think the plan would be so that you can write your JavaScript and run it anywhere, essentially. Jeremy: Which would be nice. And it's probably gonna be easier to create standards now that IE11 is dead. Michael: Right. Jeremy: Officially gone. Michael: Yeah. That's certainly true. Jeremy: The bane of my existence was IE6 for so long. When I was just doing web development. Michael: Oh, I certainly don't envy any of the standards people, any of the sort of API and standards people, especially in the JavaScript world. Because you know, the number one tenet is basically don't break the web. So anytime people are like, 'Hey, we should build this new thing.' It's like, okay, here are the 2 billion things we need to consider, if we're gonna add this thing. It's like, you know, you don't want to break this random website that was written in 1996. Jeremy: Right. So, well, so this Winter CG group. It's super interesting. I mean, web standards is just something that once, you know, what was it? It was the gecko first and then it became the Chrome, the I forget what it was called, but? Michael: You can probably just look at any browser user agent and figure out the order of like, how it started. Jeremy: But everything sort of started standardizing around certain things. And I think that was just great because then it allows people to build more things for more systems and

more compatibility across stuff. And I think that that's something that I'd love to talk to you a little bit about too, is just open source in general. Cuz you've done a ton of open source projects, including some really, really popular ones like Dynalite and Lambci. I don't know if you ever really did much more with Yumda, but I remember we talked about Yumda way back then. Which was some pretty cool stuff that you were doing with that. And you actually wrote, and I might get this wrong, but I'm pretty sure you wrote the original, like local run time for Lambda functions that the Sam team eventually used. That might be a sore object. So we can you know, put that aside. But I'm just curious, like with all the stuff that you've done, and I know you took a little bit of time off and like you said, you know, when you, you were away for a while taking some time, you didn't work a lot on those those open source projects. I'm the same exact way. I've been so busy. And it's just like, trying to get back to those projects and get my head back into the space where I was working, the reason why I created 'em in the first place, and some of these other things. I've moved on from some of those technologies too. So it's really, really hard, but I'm just curious to get your thoughts on just being an open source maintainer and your perspective around that. Like, what what's that, what's that been like for you? Michael: Yeah. It's been really interesting. I'm sure you could have like hours long chats with people about this. You guys could be my therapists. Working on open source and, you'll see, I think this is true for many people who have done it, there are so many things that are so gratifying about it. It's so wonderful to be able to, sort of, contribute to the community and the barrier to entry is so low now. Like, it's very funny to think back to a time when open source wasn't the norm. Like, early in our careers, that was the case when, if you wanted, even if you just wanted a library or something, it could be really difficult to get a software library. You need to pay for a license or even if it wasn't pay for a license, the licensing was sort of a big concern. And it's fascinating to see since then, just how much open source has taken over the bulk of so much of the plumbing, of software that's built today. And I guess it probably, there's heaps of reasons for it, I'm sure. Part of it is, it just does feel really good to build something and put it out there, you know? And, just the joy of, I think for many people who are in the software world, you get joy out of building things. And that's sort of why you stay in the business and why you keep doing it, is you just enjoy creating software. And you enjoy scratching itches. You know, a lot of open source software is created just from scratching an itch.There was this thing. It didn't quite do what I wanted. I'm gonna write it, but there's no, you know, what's the benefit in me kind of keeping this just

to myself? Or maybe just to my company, you know, I guess things get a little bit complicated there. But certainly if you're just writing something to solve your own sort of developer pain. I think a lot of the time when it is, 'oh, I'm writing this for something that I'm doing at my job,' there's just the question of, is this core IP for my company or not? You know, is this core intellectual property? If not, I think, these days companies are just a lot more open to, 'well, yeah, that's fine.; You know, just release it as a library or as a little helping thing. And people, I think, have seen the benefit of. the branding that comes along with that. Like, 'Hey wow, this company built this particular thing or this company built this particular thing.' Actually, yeah, I'm thinking even today, like we write a bunch of Go code at Cloudflare and there's a particular light, and we use Kafka, which is a messaging service. And there's a particular Kafka client out there, Sarama, written by the Shopify people. And, you know, we just use that client. But then Shopify's a customer of Cloudflare as well, you know? It's like we're a customer of their code. They're a customer of us. There's lots of cool sharing and I think there's a real community aspect to it that is great. But having said all that lovely stuff, people are people, you know? And we know this from social media, we know this from anything. I guess, once you just kind of, it's very easy to forget when you're using software and you're getting frustrated with it and it's buggy and you're trying to do something in your day job and you can't get past this point because maybe the documentation's bad or maybe it is actually buggy, or maybe there's just something wrong with it. That's super frustrating. And you're like, 'Oh God damnit, this thing doesn't work'. And you know, in that moment, it's very easy just to go and leave a snarky comment or a GitHub issue or something, and just be like 'This thing's broken it doesn't work.' And I think, plenty of people, of course, they step back and I think by and large, actually the open source community is great in the way that people interact and write issues generally is actually pretty nice and pretty considered. But it can take a toll after a while, I guess. If you just feel like, 'Oh, I created this thing and the creation was really fun. But now I'm having to maintain it.' Now, yeah, there's this really weird edge case that this person has and how much time is it gonna take me to fix that thing? It's probably gonna take hours and that's not gonna be like joyful hours for me. So what am I actually getting out of this? You know, and there are a bunch of things there's, I guess there's a bit of pride. There's a bit of, well, I feel like I made a promise actually to the community, when I put this out there. I kind of, by putting this out there, I kind of made a promise. 'Hey, people use it.' Even if I didn't say use it. And a lot of time people put stuff out

there and they're like, 'Hey, don't use this. I'm just putting it out there. Please don't use it in production.' Then, you know, a few weeks later, 10,000 sites are using it. But yeah, I think there's that. There's this element of, 'Well, I kind of promised people that they could use this thing and so, yeah, with great power comes with great responsibility. And there's a certain responsibility to keeping your open source libraries up to date. If you want people to be using them. And vice versa. If you're using an open source library, you have to keep that in mind that, you know, is this person gonna be keeping it up to date? And if not, what options are there, will you fork it yourself and look after your own fork of it? Et cetera, et cetera. Rebecca: I was just gonna say, so end of this open source question, I have multiple sub bullets and these sub bullets, it's something that you've touched on, I think, in the last couple minutes. You've touched on each of them and one is ensuring quality and consistency. Are there tips and tricks to doing that? Is there something that you should know going in as to someone who's gonna be an open source creator? What do I need to know? Do I need to schedule all my time? Does this have to end up being like on the calendar? Like how do I need to even allow myself the time and space to, to actually maintain this? But then I think we can set that bullet aside for a second, because I think the two other bullets that I have- one is, you know, you called it scratching an itch, or maybe solving a point in time problem. And so it's this bullet around ensuring longevity. So not only how could we do that, but like, should we even try? Or at some point, is it like, 'Hey, I'm gonna let this self-destruct over the next six months to 12 months to two years to six years' or whatever that timeframe is. And maybe it's okay. Like maybe it's okay. That it goes into like obsoletion over time. Michael: Right. Rebecca: And then the last bullet it was about then how, if someone is going to use a library, right? Like what's the best way for them to test the usefulness or reliability or longevity of one of those projects. Like what would you say? Like, Hey, obviously it's, you know, some people are very clear and they're like, 'don't use it in production.' And then later, like, a month later it's 10,000, but like, yeah, are there red flags that one person should look out for to be like, okay? Michael: Yeah. Yeah. All very interesting questions. I think as you were talking, I was realizing that, of course, open source runs a huge gamut, right? There's there's people that write libraries and little tools, you know, like Jeremy or myself. And then there's huge projects like Kubernetes or like, these massive projects- Chrome, you know. Like just huge projects run by teams of people at a company. And they're probably, I guess I have less experience at that sort of scale. You know, at that scale, it's almost like running a commercial

operation, in a way. It's maybe, well, I guess you're doing it as your day job. I was gonna say, is it maybe even more thankless because people feel even more justified in yelling at you when something's broken? But it is, I guess, in those cases for those big companies they're being paid for it. So I guess there's an element of that as well. But I guess that wasn't the sort of open source that I was thinking about or talking about, but it is a very important part obviously of the kind of ecosystem. But yeah, getting to the question of longevity, I think it's a really hard one because for a long time, I prided myself on someone who kept their libraries up to date. And certainly, you know, I had some principles in mind. Some of these are sort of maybe JavaScript ecosystem specific, but maybe not. I think I've actually seen similar problems in the Rust world and the Go world and other places where dependencies are a real problem. And not just with open source, obviously with any library, but because so many libraries that you use now are open source. They rely on other libraries that are open source and they rely on other libraries that are open source. And, you know, you can end up with these sort of massive dependency trees and from very early on, for various reasons, I was always a fan of, you know, no dependency, or very little writing code that had very few dependencies. Now that sometimes means of course, reinventing the wheel a little bit. Or, you know, maybe copying and pasting and attributing some MITor BSD licensed code or something like that. And, so yes, there's duplication of effort there. And potentially if the thing that you've copied and pasted has security issues or whatever, then you are not gonna get the benefit of someone else, you know, updating that. But for the most part, the sorts of code that I would do that for were very sort of small one liners, very small functions anyway. Your very, very small data structure or something like that. I haven't run into any security issues with that stuff, but I could imagine that it could happen.But the advantage of that of course, is that then when people install your thing, and 6 months down the track, if you haven't made any changes to it. Well, no changes are made to their code base either. You know, the problem can often arise when you install a library. The library itself hasn't updated, but some of its sub dependencies have, and they get updated and then maybe something breaks because, you know, there's just, at a certain point, it gets so far removed from the original library or the original utility or whatever, that they weren't even aware that this sub library was doing this thing that's now broken. Jeremy: It just gets heavier. Yeah. So that would be one piece of advice. And I'm sure I could think of many examples where that's not a good idea. But generally I feel like reducing the number of dependencies that you have is a good rule of thumb, if you're writing open source.

And if you're picking an open source library, especially picking one that has fewer dependencies, I feel generally as a very general. 'you're gonna end up with less headache down the track 'and less hair pulling out, less issues trying to debug it, less jumping around, even just jumping around the file system, trying to figure out, 'wait, where is this coming from?' Which particular of these hundred dependencies is this behavior that I'm seeing coming from? Yeah, so I think that's, that's a good rule of thumb and a nice sort of design pattern to keep in mind. Well, Michael, I hate to cut you off, but we're out of time. And I think we're gonna have to have you back on just to have an episode about open source, because I got a million things that I'd love to talk to you about with this. Especially things like, you always, like, people leave comments and they're like, 'Oh, this doesn't work, whatever.' Or 'I need that to support this.; And you're like, 'Okay, well just, you know, create a PR.' If you've got the time, then you create the PR. And then you look at the PR and you're like, all right, there's no tests. It's like, you know, so then you're like, 'Well, I can't just merge this in and break 20,000 people who have downloaded this thing.' Michael: I know it's like they did the right thing, but they didn't quite do it a hundred percent, right? Jeremy: Right. And then you rewrite it. And you're like, 'I hate this. Why is this so tough?' Anyways, open source is amazing and scary and terrible and also amazing at the same time. Michael: I should drop a plug and say that Cloudflare Workers run time is being open sourced as well, which is super cool. So yeah. So at the moment you can't like run your JavaScript code locally in exactly the same way that you can remotely. There's lots of cool remote debugging stuff that's available. But yeah, there's no local run time exactly. Anyway, there's lots of things that are very close, but yeah, we'll be opensourcing that, so that's cool. And I think that'll be good for people to at least have that assurance of being able to look under the hood a little bit as well. Know what they're running in production. Jeremy: Awesome. Well, we will look out for that. So Michael, thank you so much for being here and sharing all of this stuff. Like I said, I think we're gonna have to have you back for an open source conversation, but if people wanna find out more about you or Cloudflare Workers and all that stuff, what is the best way to do that? Michael: Google. Google Cloudflare Workers. But I should say Discord’s one of the newer ways that we're supporting people. And there's awesome conversations there. I'm finding it so much better than any of the other sort of support forums or just general chat experiences. And it's great. It's great to see the community supporting each other as well as, you know, there are plenty of Cloudflare people on there to answer questions as well. So yeah, check out our Discord. Rebecca: And if you want to learn more about Michael specifically, you can find him on Twitter @hichaelmart, which is my favorite Twitter handle. GitHub MHart. Medium HichaelMart again. You could probably just Google him and find out all sorts of things as well. We're gonna put all this in the show notes, Michael. Usually I let you give all those alias and handles, but I'm gonna roll 'em out for you. Michael: You knew them, you knew them. Rebecca: I knew them. I knew them. Of course, I know them. That's part of my job. I actually knew them by heart. I've committed them to my heart years ago. But Michael, thank you for being our final guest before we head out for the summer. Thank you to all of our listeners who have spent time with us and more importantly, who have spent time with our guests. And I hope everyone has a really wonderful summer. DM us. DM Jeremy or myself or Michael. Cuz now you know all of his handles. Michael: Yeah, guys. That was great. That was very fun. And have a great summer. Jeremy: All right, thank you.