💻 What Launched today at Full Stack Week

All right. Hey, everyone. Welcome to Wednesday of Full Stack Week. We're super excited to talk about some of the things that we announced today. And with me, I have the incredible Pages team. So let's start with a quick round of introductions. I'll kick it off. I'm Nevi, the product manager for Pages. Obinna? Hi, I'm Obinna. I'm a developer advocate for Pages. Greg? Hi, I'm Greg. I'm a software engineer on the team. All right. Cina? I'm Cina. I'm also an engineer on the team. And I'm Glen, another engineer on the team. And you guys are in for quite a treat because this is the best team at Cloudflare, arguably. So we announced some really, really cool stuff. I don't know if you've seen it yet, but Pages is now a full stack platform. This means that you can build and deploy your sites, both the front end as well as the back end with help from Cloudflare Workers. We also announced our integration with GitLab. So no longer are you stuck using GitHub. If you were blocked on Git integration, you can now use GitLab. And then finally, we also announced some really great partnerships with some of your favorite CMSs. So this is Strapi, Sanity, Contentful, and WordPress. But today we're going to talk a little bit more about what it means for Pages to go full stack. And so I thought we'd start kind of off by talking about, you know, how did Pages start? Where did we come from? And how did we get here today? Glenn, maybe you want to kick us off? Sure. Happy to. Yeah. Well, if you don't know much about Pages, Pages is basically taking advantage of a lot of what Cloudflare is really good at, right? Which is we run data centers in 250 locations around the world. And it's within 20 milliseconds of 80% of the connected world. We have an extremely strong DDoS protection. And all the things that made Cloudflare a popular choice for big enterprise websites. But something that was always a little bit difficult is how you use it for simpler sites, static sites, or just putting your content on there. And so with our workers platform, we had a thing called worker sites that came out in order to sort of do that. Pages is really trying to look at it from a product point of view. Like what's the simplest way for you to unlock the most power that Cloudflare has? And so we started with static sites and integrating with GitHub. Now we've expanded to GitLab on the integration side. And we've made the first steps into making dynamic code run just as easily as static code triggered off of a Git build. Yeah. I think the developer experience is what we're really trying to hone in on. We want to make it easy for you to just push your code to our network. And all you have to do is really focus on what you do best. And so Sina, maybe you could talk about like what are functions? Like how does this actually work? What did we do to make this feature kind of go into effect? Sure. So basically what a function is, is it's a way for you to run some dynamic code at our edge. So you can use a function to say you want to augment a response from a static asset by adding some headers to it. Say you want to add some course headers or say you want to parse a JWT to make sure that your users are authenticated properly. You can do all that at the edge. And another thing you could do is you could build your whole, the backend of your application, you can build your APIs using functions. All they are are just basically route handler. Yeah, they're route handlers that will take in requests and serve out responses. And yeah, we've designed it to make it really easy to add dynamic behavior to your pages site. And previously you were able to add dynamic behavior kind of with Cloudflare Workers. So how is this different? Like what is the real difference between what happened before and what we're doing now? Sure. Yeah. It was possible before you could stick a worker in front of your pages site zone. But that had the disadvantage of your backend and your static site kind of being decoupled. And so when you pushed a deployment to your front end assets, you'd have to, if there were like any incompatibilities or breaking changes between your backend and front end, you'd have to go like kind of juggle the release of, you know, pushing out a new version of the worker. And there'd be like some brief period of downtime in between there. What we've done now though, is we've kind of brought the workers into the fold. So whenever you push a deployment that contains both your front end assets and also your backend code. And so those go out atomically. They get versioned atomically. So one of the features of Cloudflare pages is that we have preview environments and we have your production environment. And so anytime you push to a branch, say on your Git repo, we create a deployment of that, of your site in that preview branch. And now along with that, you have preview instances of your backend as well. So that's super convenient and super nice to share your work with people in progress. And it just kind of, again, we're really focusing on the developer experience of writing applications. And so this is all in service of that. Yeah, for sure. More about the developer experience, like what actually, what does the experience look like? Like how do I actually do this when I want to deploy a full stack application? What are some of the key features of pages? Sure. So basically you add a functions directory, a directory called functions to your pages project. And inside of that, depending on the structure of your file system, the file path actually gets converted into a wrap for your handler. And inside of that functions directory, if you have a file and that file exports an async function, an async JavaScript function called onRequest or onRequestGet, onRequestPost, onRequestPatch, all the HTTP methods, what's going to happen is that function will respond to that file path, or get requests coming to that file path. And all that routing kind of gets handled for you. And then it's up to you to just, you know, read in the response, read in the params, do whatever you need to do, and then return, or sorry, read in the request, read in the params, and then return a response. The nice thing that we've done is that it supports middleware. So you can kind of build your application up in a sort of modular way. So you can have a logging middleware, an error handling middleware that sit up at the top of your app, and then you can kind of compose the functionality of your app through these middlewares. And you can easily set up logging for your entire application that way. You can easily set up auth handling for your entire application that way. Yeah. So, did I cover everything? Definitely did. Definitely did. So, when I'm building my application, what are some of the, I guess we talked about the differences already between kind of like workers and pages. I guess, what are some of the things that we can build with functions now, now that we have this like very integrated experience? Like what, where are the limitations, or what's possible? Greg, or someone, if you want to jump in on that one as well, Obna. Yeah, I'll start. Obna, feel free to chime in. We published today a blog post with an example of an application that you can build using functions. And like Sina said, it's a really powerful sort of framework for you to just add in pieces of dynamic content to your static site. So we walk through examples of creating some API routes to return data, and then you populate this on your front end. And like Sina said, you're able to write middleware to do all the often things, but also you're able to plug into all of the existing workers, infrastructure, all of the storage that that has, so KV and durable objects. And you're pretty much able to build any app that you would on workers inside pages with this new functions functionality. So the example that we've just shipped is this image sharing platform. So a little like Flickr, upload some images, and then you're able to create a different variant powered by Cloudflare images, and share that with friends, or the public, or whatever it is that you're trying to do. Yeah. No, I was just going to add that the reason this is really exciting for me, and also for most developers and stuff, previously you would have to handle all of these dynamic things outside of your pages with a worker in front of that, and do all of that in one place. But now the story of how you create dynamic stuff within pages is easier. It's a better user experience now. I try to avoid using easy, but then it's a better user experience because now everything is sorted out for you by just using a functions folder and handling all of that. So that's really brilliant, to be honest. And one step further with the developer experience, if you just remind me, we've shipped with Wrangler version two, which was released yesterday. We've also added functionality to preview your pages and functions sites locally. So you can really iterate very quickly on your local machine, and then only deploy when you're happy with it. But of course, given pages is set up for all of the atomic deploys and preview branches and all this sort of stuff, you're pretty okay doing it on production too, but it's there if you want to do it locally. Yeah. Totally. I think this will really help you to iterate quickly. I know that we are really working on speeding up our build time. So if you really want to get changes and view them quickly, then this is a really great option for you. What I really, really love about the blog post you wrote, Greg, is it kind of shows you that all the pieces of plat player, kind of like our Lego backgrounds, are really fitting together. And we want to create this experience with all this plethora of products to really give you that seamless experience. So I think this is a really big step in that direction. What else can you build with full stack pages? What are some of the use cases that we might see some of our customers using? You can use it for server side rendering, and especially with the new React server components going out, you can use it to kind of render parts of your app at the edge and render parts of it in the client, which is going to be a really powerful paradigm. Yeah. I think just following on from that, I think this is the first release of our full stack pages. It's just a beta at the moment, and it's going to get better. But putting things out in the future, I mean, you can already connect to KV, which is this globally replicated data store for things, and then durable objects, which are these instantaneous and kind of synchronous database primitives that move around the world depending on who needs them, and R2, the storage there. Pages will allow you to connect to those as easily as anything, basically, and to consider effectively just your application and not have to really worry about where it runs or signing up to multiple services and having it all hooked together. We're really trying to plot out a future where, with some knowledge of JavaScript and a few different directories in a project, you can build and deploy something as complex as the images, demos, as a first example of. And I think once that capability becomes sort of more, well, less novel, and people start to just assume that static and dynamic code and storage can all be at the edge and it can be really close to users, and once we start to have a bit of time in that world, I think you'll find that a lot of the things that we're using today, like a lot of the frameworks and things, will start to change to take advantage of that, because one of the big areas that, obviously, the downsides to working in the Jamstack kind of world, which a lot of people do, is waiting for builds and needing to get everything just regenerated when you've only changed one thing. But now we really can let that go. I mean, we can regenerate just the pages we need to on the edge just as fast as serving static content, and we can be pushing content through the databases just as easily as we can fetch it when we're running a build. And so I think right now we're kind of like just opening the door, but the next 6, 12, you know, couple of years will be a lot of exciting progress once all these things are just taken for granted, and that's the new platform. That's how front-end applications work. It's the future. So you guys all work at Cloudflare. You guys are all developers at Cloudflare, but you also are developers outside of Cloudflare. You do projects on your own. Now that this release is out, what are you most excited to build? Like, what do you want to build first for yourself? Loaded question. I have an idea, basically, to use Durable Objects for something a little simple for what Durable Objects can scale up and people are using it, thousands of people simultaneously, all that sort of stuff. They're very cool. Good for them. But I just want to build a simple blog, but I want the idea that I can basically publish content that's all using React and server components and all the newest stuff and really kind of take that out of these build time, you know, focused frameworks like Next.js and Gatsby and things and get this idea that as soon as you click publish, that content is visible just as fast as anything else within a couple of seconds, just to see how fast I can get it. And I think, now, until this release, it's been a little bit too many sources of friction to get that working. I mean, all the building blocks were there before, but there is really nothing like the developer experience where you just drop a file in a directory or click a button on a product to connect it to a Durable Object and then suddenly, hey, you have all this stuff working. So I'm pretty excited to finally tackle that problem. Can't wait to read the blog. Great. What about you? When we were testing functions, I started to integrate with one of the front end frameworks and I think I'm excited to finish that particular one off and get working on a couple others so that other people can really start to play with this in the framework that they're already used to. And it's just a case of bundling it in a specific way so that we can get it deployed onto pages, but basically taking everything that they already know, adding in KV and Durable Objects and stuff that are Cloudflare specific, and then keep pushing it up. Again, it'll be coming out on the blog. Yeah, and who knows, maybe you guys will make some demos for other people to do the same. For sure. Oh, but Athena, anything else you want to build? I'm really just excited that I get to tinker with all of this stuff in any way I want. So like Greg said, we've been trying to do some stuff with some other people, and then we're trying to make sure that everyone that's using functions or KV and Durable Objects has the best experience. So it's more about getting dog food in our own stuff with other people already using. So the stuff that you're already using to build, and we're saying, okay, what's the experience with this? How do we make this experience better? Do we need to do some integrations to make it better? So that's what I'm more excited about right now, just figuring out how people already build stuff and how we can get them pushing it a bit further with the things that we've just released. So yeah. Yeah, I think we're really, really hyper -focused on that experience. I know I come through the Discord all the time, just hearing all of your feedback and hearing about what you have to say about the product. And not only do we want to maximize the functionality and have you be able to do everything that you want to do, but we want it to be quick and seamless as well. But I guess we'll kind of move on to how can you actually go and get started? If I wanted to go build my pages full stack site today, what am I supposed to do? How do I start? Sina? Sure. Yeah. So I kind of touched on this earlier. You want to add a functions directory to your pages site. And inside of there, you want to have some JavaScript or TypeScript files that export a function, an async function called onRequest or onRequestGet or onRequestPost, depending on what HTTP method you want to handle. And that function will receive an argument that has several different things inside of it. One of them is a request. One of them is an env, which has all of your bindings on it. So any KB bindings, any durable object bindings you have, any environment variables that you need are in there. And there's also a next function. So I mentioned middlewares before. So the way that it works is that all of your middlewares kind of get assembled into this chain. And from one middleware, you can await next, and then that'll invoke the next middleware in the chain and return to you the response. So you can use that. So before you call the next function, you're kind of in the inbound phase where you can operate on a request, modify a request. And then after you get that response back, you can augment that response in any way that you want to and return it on to the next middleware up the chain, essentially. And so, yeah, I should say that the last middleware in the chain is implicitly going to be your assets. So if you wanted to add a header to any of your assets or anything like that, you should just know that the last middleware, if you await next, eventually, if there's an asset there, it's going to reach the asset and return you the assets content. And yeah, that's pretty much it. I think it's fairly simple, I hope. Yeah, that's what we built it for, right? Yeah. It made me think of something. I know a big use case for functions before, maybe like a couple months ago, was adding headers to your site. But we actually just rolled out something recently that solves that. And Greg, maybe you could actually talk about it and how you don't need to do that with functions anymore. Sure. So yeah, like you were saying, we launched a couple of weeks ago support for custom headers. We already had custom redirects and we augmented that a little and added in headers. So it was a really common request for the product because people wanted to attach things like course headers or additional security headers or whatever it is they were doing. And so with just an underscore redirects or an underscore headers file in your build directory, we take that, parse it and automatically deploy it. And that will be applied in front of your assets. So if you're able to set different headers on different parts of your application, and if that's all you need to do, then that's great. You're able to do that. You could have done it a couple of weeks ago, but like Sina is saying, functions really takes it to the next level. If you need additional dynamic stuff, whether that's loading in just completely arbitrary responses or whatever, and those headers and redirects will still be there and they'll still work. So as you're fetching with Next to get to your assets, you can still retrieve those and modify them further if needs be. But yeah, it should all just work together really. One of my favorite parts. Oh, go on. I just wanted to follow on from that. So if anyone is watching this that isn't already in the discord, it's been a great sort of two way communication channel to be able to find out what's most important. So with something like headers, it is sort of something we prioritize because that's a really convenient way of working with these files. Even though you can use a worker for it, now you can use functions for it as well. But it's important to us, I think, to design the product and the APIs to be as close to what everyone is expecting and wanting to use as possible. And so that's been a really good way to hear what the community wants. And so I encourage anyone else to get involved and chat to us. Yeah. I think we're trying to define or balance this idea of defining the future, but also really studying what people do today to make sure that transition is really, really smooth. But I was just going to say on headers and redirects, I think one of my favorite parts about what we just announced today and our release is the UI changes that we have in the dashboard, which Sina really took point on with the design team. Once you make your deployment and you deploy your sites and click on a specific deployment, you can see all of the functions. You can see redirects, your headers. It's just a really, really great experience overall. So I encourage you all to try it out. But I guess the last thing I kind of wanted to touch on is where, and Glenn, I know you talked about this a little bit, but where do we see ourselves or what's coming beyond? What's the future of Pages? What's the future of Jamstack? And how does Pages kind of tie into that? Well, yeah, I'm happy to rabbit on about this for a bit. I've been talking about this for years now. I think that basically what we have now is a point to reset a lot of the assumptions about what front-end code, what JavaScript code, and what frameworks are capable of. For the last few years, Jamstack has been extremely successful because it gives you a way to get everything nice and fast. And if it builds, you know it's going to run perfectly. And now what we're basically looking at with Pages is a world where, hey, you can run some stuff at build time. You can run some stuff at runtime. It's always going to be fast. The servers are never going to go down because it's a big global network and has all the DDoS protection. All the reasons you didn't want to run a server before start to go away. And if you look at what's coming out of the React community and other areas like the Svelte framework, I think what we're going to see is a real explosion of innovation here with people starting to reevaluate, you know, oh, okay, that worked pretty well a few years ago, but hey, maybe we don't have to do that so much anymore. Maybe it's, you know, if you can always push a deployment to a URL that is private, you know, and doesn't have anyone looking at it yet, then it sort of takes some pressure off doing some other things because you can always just spin up a branch, spin up a deployment, run some code against it, test it, you know, if it's a real live production deployment, you can test it for performance, which is something that's very difficult to do when you've only got local dev previews. And so I'm really excited about a few frameworks. Remix is one that's very exciting, that they're making some noises about opening source sometime soon, which will be very exciting to play with. React server components has been picked up by a framework called Hydrogen coming out of Shopify. That's very exciting as well. Next.js have just announced a big shift to running on more compatible with the Edge. Nux.js has got a release coming up, which is all Edge rendered and SvelteKit is already kind of there. It's already looking pretty good. So with all of that work, basically what we have now is the ability for them to target something that's faster and smarter than the platforms that we've been using before. And so I think it's very difficult to anticipate exactly how it's all going to shake out, but it's certainly something I've been excited about seeing come to fruition. And so today is a big day because for me, it's this point where, hey, okay, anyone who wants to write the next framework of the next 10 years, be the next React if you want, you can deploy it to pages and it'll run faster than anywhere else in the world. So you've got a weekend coming up and maybe you want to hack on something. Yeah, definitely. Anybody else want to add to just visions for pages or visions for Jamstack in general? One thing I think we forgot to mention before was we have direct compatibility with workers. So if you include a file named underscore worker.js or ts in your build output, that will actually get deployed as a worker for you. So we're hoping that framework authors target that as a deployment target for generating the dynamic parts of your site. So that should hopefully make it really easy to integrate with pages. Yeah. And so the functions API that we've written, in fact, is using that mechanism behind the scenes. And so functions is our best approach of making the really common things, the sort of things you'll see in the example today and making them as easy as possible for interfacing between say an image storage service and durable object and a KV and as well as all your static assets. Basically the best way you can build that site today. And then the underscore worker.js is really the future proofing, right? And it's anything that you can dream of, you can compile to a worker and we'll deploy that as well. And so you can either use the version that's there now or you can dream up a new one if you prefer. Yeah. Or even if you're just wanting to try out the pages platform and you've previously just been using workers, you can get started immediately by just taking your current worker and taking advantage of all of pages as infrastructure for their preview deployments and everything that we have to bring. And rollbacks actually. Rollbacks is something that didn't get a lot of mention today, but to be able to just go, hey, I want to jump back three versions to a version of my worker and my assets and everything that I know was okay. That can be extremely valuable when something's going wrong. And that's something that's really difficult to build yourself. So I'm very pleased with that feature. I think a lot of people- Sorry. Go ahead. And it presents a really clear path for people wanting to migrate from worker sites as well. Eventually, we'll be able to take whatever it is that they're currently running on workers and deploy that as a pages project in the near future. Exactly. And just on that point, I was actually just going to say that the one thing that's kind of keeping us from having you migrate worker sites to pages immediately is the uploading of pre-built assets, which we are so happy to be working on next. But I know we're really close to time, but just wanted to say thanks to this wonderful team for always shipping out the most requested features. They're superstars. And also give Pages with Functions a try, and we'd love to hear your feedback in the Discord, but happy coding. Yes. Thanks, everyone. All right. Thank you. Bye. Bye. Thanks. Bye.