Paul: Hi there and welcome to PodRocket. I'm Paul, and today with us, I have Greg Brimble, and he's a systems engineer at Cloudflare. Welcome to the podcast, Greg. Greg Brimble: Hiya. Thank you for having me. Paul: Thanks for coming on. So recently you spoke at Remix Conf? Greg Brimble: I did, yes, just the other week. First time out in Salt Lake City, so that was nice to go and explore and see the place. But yes, I gave a talk called Full Stack Fast: Data on the Edge at Remix Conf. And yeah, just got invited to chat about it here. Paul: Did the talk go well? Did you have a good time? Greg Brimble: Yeah, I was pretty happy with it. It went as well as I could have hoped. So yeah, it was my first in-person conference talk, so that was fun. Great to meet all the other speakers and chat about Remix and just the web in general. Yeah, it was really good fun. Paul: Yeah, so like you mentioned, hopefully we'll touch upon the topics that you talked about in that conference. And in general, we're going to talk about the Edge and how the Edge is changing web development today. And you're specifically working on the Pages component of Cloudflare right now, right? Greg Brimble: Yeah. Yeah, so Cloudflare traditionally is a CDN, Content Delivery Network, and the way that typically works is that you'll have some origin server somewhere in the world and Cloudflare sits in front and then delivers that content to your visitors from all over the world. The idea being that with a big global network, you can deliver more performantly and you can sit in front and watch for security and just keep your website reliable. That's the sort of premise of Cloudflare as a CDN. Greg Brimble: Pages and Workers are sort of a stab at a developer platform and offering originless or serverless products to developers. And that just means that you don't need to have the origin. Cloudflare can be the thing that delivers the content straight from its network. So yes, I work on Pages, which was starting off as a JAMstack platform for developers, so you can just host your static sites, like a Gatsby site or whatever, but since we launched Pages Functions last year, we sort of started expanding our offering and now we're able to offer compute, and that brings about support for Remix, and SvelteKit, and these other full-stack frameworks. Paul: So you mentioned JAMstack. For people that might not be familiar with that, what does that stand for? Greg Brimble: JAMstack is JavaScript APIs and Markup, I think. So this is sort of a technology stack that came about, I guess, 2010s sort of time. And the idea was that we would break out all the static pieces of your application, all of the JavaScript, and the HTML, and the images, and your style sheets, and all these sort of pieces that rarely change, and deliver them on a CDN. And that would mean that when your user comes to visit your website, they're able to just quickly download those pieces and then you can load out all the data and stuff separately. So you get a really fast page render and the rest of your app can follow. Paul: Gotcha. Awesome, thanks for that quick overview. So when we hop into speaking about the Edge, could we quickly define what the Edge really means, and kind of going back, maybe with the history of how websites were constructed and why we arrived at the Edge now as being the go-to solution? Greg Brimble: I'll start with the history and then get onto the present day. So sort of back in the day of when you had a rented server, like a PHP instance and a MySQL database or something, you were renting some virtual shared machine or something like that, and you were typically renting in one location and then all of your visitors to your website were phoned to that machine, and then the machine would render some response and it would be delivered back to you. So if that one machine went down, then your whole website went down. So it wasn't very scalable, but it was pretty good because everything was all in one place and it was quite easy to manage, generally anyway. Greg Brimble: So then JAMstack came along and we broke out the static assets part of your app, but kept your data wherever it was. Then we had sort of the next iteration of this was people starting to realize that the data being in that one place was kind of not great because it meant that in order to render your app for visitors all over the world, they still had to phone into this one spot. So the likes of Fauna, and other data platforms came around and they started delivering your data on their own networks, so that it meant that your visitors were able to just make a relatively local request. They only needed to hit somewhere within their own continent rather than across the ocean. Greg Brimble: And then now, with more powerful CDNs and stuff that are able to do compute and storage, we're able to have full apps running on these networks. You don't need to have necessarily collect to external data platforms. So the Edge is sort of just like the terminology that we use to describe the network of machines that we have all over the world. So Cloudflare has, I don't know, 250 or so locations. And all of these places are just whenever an incoming request is sent to Cloudflare, we just route it to the nearest data location and that will hopefully just give the best performance for that request. Paul: Now, out of curiosity, you say the nearest location. Is there a lot of other magic, I guess, we could call it, going on in terms of like, what if one location is really bogged down because there's just like a ton of people there? Would you guys go send it to the lowest latency location? Greg Brimble: Yeah, definitely. So there's a whole bunch of different routing rules that go on, and I'm not on that team, so I don't know half of the technical magic that they do, but pretty much exactly like you said. So we have a whole bunch of different locations. Sometimes they might be overwhelmed because there's a whole bunch of traffic, and it's really interesting to see the circadian cycle as the day progresses, you see parts of the world wake up and then those data centers become hot or overwhelmed, so there's that. Sometimes there's maintenance running, sometimes there's just like internet congestion, like some backbone or something is down and we need to take a different path or whatever. Greg Brimble: So the way that Cloudflare works is we have an Anycast network, and that just basically means that we broadcast all of our locations on the same address. So whenever you make a connection to Cloudflare, it can go to any place, it doesn't really matter. And then I guess the smart people who are in charge of the network, figure out how exactly best to route this. There's a whole bunch of automation there, but sometimes they'll manually take one down if there's a problem or whatever. But yeah, the idea is basically we'll do a best effort of, "Can we get this to the closest and most performant place for you in order to actually answer that request?" Paul: Now Cloudflare has not just like these Edge sort of components. I mean, you could also call the Edge as the CDN. Like a CDN is also sort of an Edge technology, right? You're taking content and distributing it. Greg Brimble: Yeah, really the Edge is just like the concept of having computers near to your users that aren't in their control so you can run stuff securely on there, but the point is that it's close and nearby to wherever your users are. Paul: So the Cloudflare Workers technology is really great. I've been very happily using it myself for a few projects. How is that different and similar to the Pages arm that you're on? Greg Brimble: Yeah. So I think Workers came first maybe, oh gosh, 2019-ish, 2018 maybe. And that was our first serverless offering. So we were able to run a worker between the origin of whatever you had and you could manipulate the incoming request or the outgoing response. And that was really cool because it meant you could do really programmatic stuff like adding headers, or A/B testing, or whatever it was that you wanted to do to that request. And then we had something called Workers Sites when we added KV, which was our key-value data store. And that let people host sites entirely on Workers. It was really cool, but it was self-managed. And like I say, it was using KV. This was our first data offering as Cloudflare. Greg Brimble: And so yeah, people were spinning up, me, myself included like our portfolio sites and things like this on this cool new tech. And it was really pretty cool, but we realized that worker sites was quite difficult to manage. You had to write your logic for getting the assets out of KV and your writing was quite difficult to manage and stuff. So we came up with Cloudflare Pages, which is basically just a managed version of Workers Sites. So you would build your Gatsby site or your Create React App or whatever it was, have an output folder of static assets, they would be put into KV for you, and then we would just deliver on our network. And that's basically what Pages was as a JAMstack platform. Greg Brimble: Like I say, last year we added Pages Functions and it's in beta at the moment, and has been for a few months. And that let us add in sort of Workers compute onto the Pages platform as well. So you're able to not only just serve the static assets, but also do all of the stuff that Workers does as well. So that's really what you need for the fully-fledged full stack app. And yeah, it's been really cool. We've seen SvelteKit, Remix, and Qwik, I think are the three frameworks that we have at the moment. Obviously more to come as the industry is moving in that direction and also the frameworks add support. It's been really cool to see everyone adopt this new way of writing apps, like Edge native sort of thing. Paul: Right. It's almost like taking a backseat from the operator's chair of taking your app, your portfolio site or whatever it is, and you're just kind of summing it up to the service you're paying for and working with strengthened weaknesses to really accomplish what you want to accomplish. It's a different way to think about the whole pie. Greg Brimble: For sure. Like if you're just building a portfolio blog site or whatever, you shouldn't have to worry about scaling, or Kubernetes, or anything. Obviously that's so far removed from the problem you're actually trying to solve. So the Edge, and serverless, and all this sort of stuff lets us just abstract all of that away. And you're right, there are pros and cons to it. It means that you don't get a full Node environment, so you don't get maybe some of the libraries that you're expecting to work, but the obviously pro is that you just don't need to handle any of the resources for serving that website. Paul: Do you find Pages a good environment for people to employ the strengths of server-side rendering and certain speedups in that area? Greg Brimble: I certainly hope so. That's certainly what we're trying to do. Pages is sort of like an easy on ramp onto the serverless world. At least that's what we're trying to be. So we have like Remix starters, and Qwik starters, and all this sort of stuff. So it's just like a npx create-remix or something like that. And then you select Cloudflare Pages and you're pretty much good to deploy straight away, just tweak at your will to make it into whatever it is you actually want to be serving. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show. Paul: Now, when you deploy something to Cloudflare, it automatically gets propagated out to all these different nodes and locations, so it's close to your users. Are there any sort of paradigms that you would like to talk about or suggest to people when they're writing applications either on Pages or on Workers, that will help them take advantage of this behavior of things being deployed out in this way or certain advantages for other features that you guys have over at Cloudflare? Greg Brimble: Yeah. So the big thing for me and what was the premise of my Remix Conf talk is data. So it's really easy if you're operating like a stateless app that doesn't matter about any of the other previous requests, you just take in one request and give it an answer. That's really easy to do, but when you have state and you need to keep track of who a user is or some document that they were working on, you need to save it or something. That's when it starts to get complicated. And the reason it gets complicated is because all of that data is dispersed all around the world, so in the case of where you have like a single server that you've rented and it's running in one place, it's really easy, you just have a database and it's all just kept there and you can just look up the thing. Greg Brimble: But let's say you're working on like a Google Docs collaborative environment sort of thing, and you have users from all over the world working on this one thing. How do you avoid collisions and things like this? In the case of a single database, it's really easy. You just persist and then the last one that wrote wins, but in the case of distributed data, it can become a lot more complicated. So we at Cloudflare have a bunch of different data products, so we started with KV and then we came up with Durable Objects, DO, and then R2, and in the works is D1. So a whole bunch of somewhat obscure names, but they all solve different problems. Greg Brimble: So KV is our key-value data store, great for storing anything that is read very often and written to infrequently. So that's something that's highly available, but not strongly consistent. Durable Objects is the opposite, it is strongly consistent and isn't highly available. There's only ever one of them in the world. R2 is like a blob object store and D1 is going to be our first SQL database. So there's a whole bunch of stuff we can get into about D1 later, but we offer all of these different types of products, these data products to solve different types of data problems that you have. So based off of whatever the data is that you're trying to save, you should be choosing to store it in these different types of products for their different properties that they have. So yeah, the biggest problem is just deciding when you're modeling out your app, how can I make this data persist in some way that makes sense for whatever it is? Paul: Now, one thing I do know about R2 is it's part of this bandwidth alliance, right? So you can basically egress to your heart's delight for no additional charge once you get something in. Why does Cloudflare do this? Because I would find that pretty unique in the current offerings of the cloud products out there. And how do you guys pull that off? How do you make that work? Greg Brimble: Yeah. So I think I might be wrong, but I'm pretty sure all of the things under the Worker's umbrella have no egress costs. And you're right, it is a differentiating factor. Most other places do charge for bandwidth, be it the JAMstack platforms that compete with Pages or object stores like S3 or whatever. They charge for bandwidth. And the reason we don't need to is because we started with this massive CDN. So we, as a company invested really highly in making all these connections with the different internet providers and all this stuff, so that we're able to offer competitive bandwidth, like peering, and pricing, and all this sort of stuff. And because we started with that and that's like the bread and butter of Cloudflare, I think we're in a position to offer it for free for our customers. Paul: Yeah. I mean, it's really cool. It kind of opens up the door for a lot of interesting business opportunities, I guess, for people who are trying to distribute and store data in a much more cost-effective way. Greg Brimble: Definitely. Yeah. For serving applications and also as part of just like vendor lock-in. It means that you're not scared to start on an app on Cloudflare and fear having to then migrate because of some massive egress cost that you're going to have to face. That just isn't the case and obviously isn't what we want to do for our users. So yeah. Paul: So you're mentioning also Pages is coming up with this compute and even a serverless sort of environment functions, right? Do you feel like Cloudflare is chasing an idea to become a highly available Edge distributed service offering that most people would find aligned with something like AWS that's been out for a while now? Greg Brimble: Certainly like AWS have their own Edge compute for Lambdas and Lambdas@Edge as do other networks like Fastly, I think there's this compute at Edge. So it's something that the whole industry is looking at. Workers, I think was pretty early to the industry and we've been adding more and more products and features onto this platform to hopefully let people build complete, fully-fledged apps all in one place. So yeah, it does compete with these other companies and their products for sure, but it's a growing space and it's not like we've capped out, so I think people are pretty free to get started with any of these providers, start playing around with how they build apps on the Edge. And then hopefully, like I say, we're in a place where it's relatively easy to move between these different companies and products. Paul: So speaking of the whole stack and all the products that we're mentioning here, what is in your definition, the Cloudflare Disco Stack? Greg Brimble: Ah, so the Disco Stack is something for Remix. Remix, a couple of months after they launched, they had this idea for Remix stacks, so I think they launched with three official ones. Indie, grunge, and something else. I can't remember off the top of my head, but they are just sort of templates to let people get started with a production-ready app that you can just sort of tweak to whatever you need it to be, but it comes with all of the things that you need to deploy. So that might be some database somewhere, it might be an authentication service or whatever, and they have all of the components of your app ready to go. Greg Brimble: And they encouraged us and other people to write their own stacks that took advantage of whatever it was that they could offer, so with all of our data offerings that Cloudflare have and are getting with D1, the idea is that we'll be able to offer a Remix stack for people who want to build Remix apps and have all of these different types of data products ready to go for anyone who wants to get started with it. Paul: Yeah. It sounds like Remix is really well positioned right now in the direction that these Edge technologies are moving because it has the really good support for tying into these server-side services. It's kind of like next gen. Greg Brimble: Yeah. So they are one of the most strongest proponents of using standards, like web fetch standards. And the reason they're so interested in that is because they want to be platform-agnostic and they want their Remix app to be able to be deployed in as many different targets as possible. Cloudflare Pages is just one of them. But by having this sort of standardized approach, it means that they're just able to take an app and transplant it into any of these different targets. That's really cool. Greg Brimble: What's going to be interesting is to see how all of the companies and products align and get to offer serverless standard environment for all these things to run, but it seems to be going in that direction. So yeah, it's an exciting future and Remix are probably one of the first to really jump in and take advantage of it. Paul: What's one of the ways do you think it really stands out in the ways it takes advantage? Greg Brimble: I mean, if you just look at their documentation for Remix, they just constantly link to Mozilla's MDN, I think developer network docs that they have, and it's just constantly referencing the standards that already exist, that already work in browsers, so it's nice to have that sort of high quality documentation and Remix just sort of sprinkled stuff on top to make it easier to use, but isn't anything fundamentally different from what's already there. Paul: Gotcha. So it has kind of like a minimal approach, but a very solid foundation. Greg Brimble: Yeah, for sure. Yeah, they encourage you to use the platform, as they call it, as much as you can. And that just makes sense, that's been how you write Cloudflare Workers for since day zero, so it's great to see them adopting the same approach. Paul: Well, Greg, is there any other things that you would like to bring up about what you're excited about to work on with Cloudflare Pages and other exciting examples or use cases that you've seen as a kind of closing topic? Greg Brimble: Yeah. Well, I'll say the Disco Stack we were just mentioning, it isn't ready to go just yet. We're sort of waiting on two things. One is our D1 database being made available right now, it's being worked on as we speak, and I think closed beta very shortly. So until that's ready, we won't really be able to offer that as part of the Disco Stack. And part two is resource provisioning, which is this feature that Pages is working on offering, and that will let us detect requirements of a project and then help users provision the requirements as they do their first deployment. So the idea would be that you would have like a Disco Stack template that you would just get started with, and then go, "Oh, we see like a D1 database and we see a Durable Object that looks like this." Greg Brimble: And we would walk you through the process of creating those and getting them instantiated before we can actually do your deployment. And hopefully that just makes the onboarding process really easy, no more following a hundred steps in a readme. It's hopefully just a really nice, like I say, onboarding ramp to the serverless world. So yeah, that will be coming in a couple of months. And at that point, Disco Stack will be ready for people to play around with. So really excited to get started working on that and hopefully get it in people's hands sooner rather than later. Greg Brimble: In terms of what I've seen, there's been so many completely different types of apps that have been built on Pages and Workers. Some with Remix, but yeah, it's just so... I wouldn't even know where to start. So people are just building like little services for their business, like the authentication service or whatever, and they just are swapping out whatever they had old with this new worker service. And some people are building just simple marketing sites or full stack apps taking advantage of the whole thing. But it's really, really cool to see all these different types of things. Greg Brimble: And we have a Cloudflare Discord server that is just a fantastic place. Like people are constantly posting all these different types of examples and things, and very often open source, so you can just go pick through, steal all the good bits, and make whatever it is you're wanting. Paul: Fantastic. Yeah. I mean, we can get the Discord link and put it down below for anybody listening that wants to go check it out. Paul: Well, Greg, thank you for your time coming on and talking about Pages briefly, the JAMstack and the Cloudflare Disco Stack. And we'll be excited for when, what is it? D1 comes out. That's the name of the- Greg Brimble: That is, yeah. Paul: Postgres. Great. Is there any other socials that you would like to mention or shout outs? Greg Brimble: I'm @GregBrimble on just about everything. Twitter is probably the best place, but yeah. Any questions? Just let me know. Paul: Great. Greg Brimble: Thanks very much for having me. Paul: Thank you, Greg. Speaker 4: Thanks for listening to PodRocket. You can find us @PodRocketPod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.