🏗 Cloudflare Pages Updates

Hello. My name is Greg Brimble and I'm a systems engineer working on the Cloudflare Pages team. And today we had quite a few announcements as part of Platform Week, but I just wanted to spend a bit of time to go through with all of you and just sort of show off what the team has been working on in the past few weeks and months and some of the new features that are available to you as developers for using the Pages platform. So all fingers and toes crossed. We're going to do a bit of a live demo of some of this stuff today, so I'll just sort of get started straight away with sharing my screen and going over some of the new features we've just released. So let me get rid of that sharing bar. So one of the biggest improvements that we've made to the Pages platform today is a complete overhaul of our build infrastructure. So Pages, for those who aren't familiar, is primarily a CI platform. So we integrate with GitHub and GitLab. We watch that for changes to your source control and then we trigger builds to create your website and then we push that to our edge and make it available to your visitors. So previously we were on our first iteration of build infrastructure and that took some minutes to initialize and actually perform the build before it was available for you to see in both your production and your preview environments. And we know that that is just a source of pain for developers when you're trying to get something quickly out of the door to make a hotfix or just wanting to develop and see your changes being made quickly as you try and iterate on your work. So on the left here I have a project which is connected to GitHub repository. And on the right I have my Cloudflare Pages project, which is already connected up to that repository. So let's just make a commit here. Oh. Live demos. There we go. And if we push that up, hopefully we see Cloudflare picking up this push and see the new deployment available. So we'll go in quickly and we'll take a look at what's happening. So one of the, like I said, the first thing is the speed of these deployments. Previously, this would have taken about 2 minutes before any work happened. But you're also seeing immediate live feedback as the build is happening. Right now, we just have a very simple project with our "Hello, world" as our build step. But you saw these logs coming in as they were being processed. Previously, you would have to wait until the build completed before you could actually see these logs. And it was just a nightmare coupled with the time that it took for a deployment to actually happen. And it was just really painful for developers who needed immediate feedback on why their builds weren't working. So hopefully just these two changes to how we run your builds, just hopefully make it a much better experience for you as a user of our platform. Another thing that we saw developers asking for was more control as to which builds we actually perform deployments for. So one thing that we've released is the ability for you to skip builds. So you may have seen the CI skip as a convention and their platforms have also adopted, which basically just informs anyone listening to the repository, Hey, don't act on this commit. Maybe it's because it's just a preview thing, or it was just touching up documentation or something. You don't actually need to do a full deployment so we can say, skip this build, go back onto the project and we push that up. We will hopefully see it get picked up, but this time not actually get built. So this will not ever be available in production. We very intentionally skip this because we picked up this message in your comment. We do watch for various variations of CI skip and also added a whole range of configuration options in the settings for a project under build and deployments. So you can see here for you to have control over how we build production and preview deployments and right now we're set to just default, build everything. But if you are conscious of the limits of your Pages plan and you want to only build, say, production ones or you only want to build staging or some release branches or whatever, and not every single branch that gets created, you're able to go in here and configure with some really powerful syntax, pretty much any variation of what you would need for your project and workflow. We have documentation available, of course, for all of this stuff, the skip CI messages and all of the various ways that you can configure the preview and production branch controls. Hmm. We got this released today and we saw a bunch of questions from other people about what else is coming up in the future. And part of the big reason for this change in infrastructure, not just to improve our speed, but also to allow us to build new things on Pages is so that we can take steps now for new features such as incremental builds. So this is one of the very popular feature requests that we've seen. People want to be able to just pick up the changes that are happening to the repository and only build those relevant pieces of their website or app. And this will obviously bring down the time to build for their projects and hopefully just improves the developer experience. One other thing that we've seen a lot of requests for and we're very aware of is our build image. And right now we're still using the same build image that we launched with last year. And as a result of that, it's a little bit out of date. So with this new infrastructure, we'll be able to take a look at updating this in a way that lets people continue to build their existing projects without breaking them, but offers people creating new projects or some way to opt in to the latest and greatest from all of the tools that we bundle into the build image and any other stuff that we can add or let people use in their in their build. I think that's pretty much everything from the build infrastructure side. And so now we're going to show you one of the other features that we launched today, which is the direct upload. So here I have another project in my account. And let's go into a demo. Get rid of all of that. So, let's show this off. So you're able to create a brand new type of project, one that isn't connected to any Git providers. And this is a really crucial feature for anyone who's using mono repos and need to be able to configure multiple Pages projects from a single source of truth or their code repository, or they're using somebody other than GitHub or GitLab. They might have self-hosted or be using Bitbucket or some other non Git source control. Or they're using build infrastructure and themselves. They've already got their own CI pipeline set up. Maybe their build takes more than 20 minutes, and so they want to build themselves and then simply push assets to Cloudflare's Edge network that we can then serve for them. So all of the convenience that Pages provides with its rollbacks and its preview links, custom domains, all of that stuff, but without the build step, essentially. So let's just create one now. So when you create your project, you can upload a folder of assets or a zip file. We actually have one available. I don't know if it's going to be here. Let's actually go and bring this up. So when you create a new project, you can see this demo site here and that you can download. So that's actually just do that. Yep. And we will drag and drop that in. Live demos, upload zip. Now you see all the junk on my computer. Sorry about that. There we go. And that has got the wrong thing. That's right. Again. Start. There we go. So live demos not being an issue, you'll be able to just upload, like I say, a zip or a folder of prebuilt assets in the dashboard. You can give it a name. Hit save and deploy and hopefully things just work. Great, so let's continue to our project. We'll see that pop up. So I've just created a preview environment called Staging. And you can see all of our assets that were uploaded here. We can go to the project. Hopefully this is all working great. So this is the example project that we provide people just to sort of demonstrate how this thing works. But of course they can just bundle up their own project and deploy that. And there are two methods. You can either use a Wrangler CLI, which was just updated officially to version two yesterday, or you can use the dashboard as we've seen. So let's try it with Wrangler and I can show you the process for that and Pages publish. So for those that aren't familiar, haven't, maybe haven't been using Pages functions and we do have a native integration to Wrangler now for Cloudflare Pages. And this new command that we've just added today is the publish command. So you can give it a folder. Let me actually just show you what I have here. So I have a public folder and if we actually go into that, we can see the same thing as just this static demo site. Now we go Wrangler, Pages, publish. Can we specify the directory that we want to publish? And that is public and hopefully everything just works. Hey. So this is uploading all those files, creating a new deployment, and we can go back onto our thing and see that this has just been published as well. We can go to the URL that's open to my other browser. I promised this over here. And that's alive as well. So. Really a quick way to sort of prototype new websites. If you just want to share a folder of static assets and you'd be working on something with a colleague or whatever. Or if... Or you can replace your entire... Build infrastructure pipeline with this. Like I say, if you're using something other than GitHub or get GitLab or you need more than 20 minutes to do your build. And one thing that I totally forgot to bring up in my terms, but we have also released a Pages action for this. If I can spell. And this will somewhat counterintuitively let you deploy to Pages with GitHub actions. But perhaps, like I say, you have your own custom build step, so you do want to be using GitHub actions for the PSI part, the actual building of your application and but we'll let you deploy to Pages with this. And internally this is just running Wrangler pages published exactly the same thing. You just copy and paste these few lines, add it to your GitHub workflows and file and pretty much should be good to go. Right. And I think that is pretty much it for a page published. Oh yeah. One other. And so we announced this day and some of the questions we got were around the limits. At the moment, a Pages project in general is limited to 20,000 files, but whilst we're sort of gearing everything up and making sure that everything is stable and Wrangler and the dashboard are limited to 1000 files per direct upload deployment, we hope to remove that limitation soon. Like I say, we're just sort of making sure that we can cope with an influx of all of these files coming from all over the place. So. Yeah. Hopefully we can raise that up to the 20,000 limit that pages normally has. And one other thing of note is that deployments at the moment aren't counting towards a number of builds for your project. And this is quite this is always great for anyone who's worried about coming up to that quota for their Pages pricing plan. But we might impose a deployments limit in the future. We're just sort of have to see how things go in terms of abuse or whatever. At the moment, though, go nuts. Cool. Like I say, I think that's pretty much it for direct upload. And so those are the two big announcements that we had today. We do also have another announcement coming on Thursday and I have been given permission to give you a little bit of a sneak peek of what's coming up for that. So let me just get rid of some of these direct upload tabs. Cool. So Pages plugins is going to be announced on Thursday. And like I said, I'll just give you a little sneak peek of this right now. So just to sort of recap, Pages functions was announced last year as part of, I think, Full Stack Week in maybe November. And what that lets you do is create a folder of functions inside your project. And we compile that folder functions into a worker and deploy it alongside your static assets. And this sort of lets you take what was previously just a static website and you maybe had to rely on traditional sort of JamStack and where your API was hosted elsewhere and you were just using Pages for your static assets allows you to transform this instead into either a fully service rendered app using full stack frameworks such as Remix or Quic or Stealth Kit and or just adding little snippets of dynamic pieces into your app. So you can just create a one off Function to do some HTML rewrite or AB testing or to add in an API end point for Proxying cause requests or all sorts of different use cases people have been using Functions for. And let me bring up my project here. So I have an example project and in there I have a public directory with an indexed HTML. And this is what we were just seeing over here. Like I said, a simple example of a Function is just a one file added to a folder of Functions. In this case, we've got date. And that's really difficult. See, we have this really nice syntax where you can just export these handlers and we will, like I say, bundle them up as part of your Worker that we deploy along the thing. So if you go to just slash date on our app, we get back this this response that's being generated by the Worker. So none of this is running client side. This is all running on Cloudflare network and Functions introduced and file based writing, which is one of the very like which was writing is always one of the questions that we saw people have when they get started with Workers. How can I decide how to delegate requests to different pieces of logic? So Functions is file based writing and you can just name a file date. We also support parameters or middleware and... Yeah, that was sort of solves the problem of writing for people getting started with Workers. And but we realized that that wasn't just the only question that people were having with Functions or Workers, rather. And often people had to do the same sort of tasks, whether it was an authorization or whether it was like building all the boilerplate for an API or an. I don't know, error tracking, whatever, all these sort of repetitive problems that people are trying to solve. And we realize that there's maybe space for a solution there, too. And so that's really what the Pages plug ins is about. So we want to be able to make distributable pieces of logic that you can publish to NPM or GitHub or whatever and share that build in not just routing, but also whatever it is that you need in order to solve some particular problem, for example, authorization or for example, air tracking or spinning up an API server or whatever. So this date file is just an example of normal, regular old Functions. But what we have here in GraphQL is an example of using a plugin, one that we will be launching, like I said, on Thursday. So if we actually take a look at what this is doing, we're importing our GraphQL plug in from our Pages plug in library. We also have a bunch of just GraphQL stuff here. But you'll recognize the syntax from before. We're exporting this on request handler and we're just saying, Hey, we want it to be this GraphQL plugin. And this GraphQL plugin takes a couple of arguments and takes the GraphQL engine and it takes our schema, which is what we've defined up above. So the like whatever this is 27 lines, almost all of this is actually totally unrelated to the plugin and this is just application specific logic that we want to implement. So here we have a schema and it takes it has a Hello and returns Hello, world. The most basic schema you could possibly make. And if we. What we're trying to solve with this plugin is all of the boilerplate that you would need otherwise if you were trying to spin up a GraphQL server. So we can actually take a look at what this plugin is doing, go into our GraphQL plug in and we take a look. You can see what we need to do. In order to make this plugin actually work is we need to parse the incoming request. We need to take a look at all of the pieces of it and extract them out, remap them over to something else. What the GraphQL engine is expecting to be called. We need to actually run the GraphQL engine so it resolves our request and then we need to return a response in a particular format, in this case, just JSON, and so that the client gets back what it is they're expecting. So this is, like I say, a pretty simple example, but exactly the sort of problem that we're trying to solve with pages, plug ins, where we sort of see this logic here being repeated in projects over and over and over again. And so let's try and abstract it away so that people can just focus on the core of their logic. And in my case, that was my GraphQL server, where I'm purely defining what my application needs in order to work. So one other cool thing about plug ins is not only do they have the sort of abstraction of logic, but they can also bring writing and static assets with them. So here we have a folder static, and let's go into it one more time. And you can see here, this is just an HTML file. And all this is the GraphQL playground, sort of like graphical, if anyone's familiar with that. And this just lets you interact with your GraphQL server in a nice developer friendly way so that we can sort of prototype and see, make sure that everything is working. So together with this Functions and. Indexed here saying, hey, I want to run this plug in on this one. Right. And needs to parse the incoming request and generate some response. Please also bring along the static asset. We publish this GraphQL plugin and it's available to mount just like this in these three lines. And so we can see that live. Here. We're seeing our GraphQL playground actually being served. And if we send it a query document, we're getting back this response from our server. And that is all with just these three lines of code that we are able to just drop in this stuff into our Pages application. Really, really cool because what this will let people do is just like I say, focus on the core of what they need and treat this stuff just like any sort of NPM package, but one that, you know will work for your page's application. And you know that we're on a Workers and like I say, it can take power. It can take all of the power of Pages functions using KV, Durable Objects, static assets routing and just sort of drop it in and augment your app. One other example I'm going to show you very quickly, because I am running out of time, is let's go back into our root. We have this throw an error, which is nothing to throw. And here we just have some function that goes wrong. And so we want to be able to sort of track errors, something that the Pages functions feature is kind of missing at the moment. We don't have all of the analytics and stuff that Workers have. We're going to get it by But until then, you're kind of reliant on third party services. So one of the partners that will be launching with our Pages plug ins is Sentry, and we have a plug in from them which will do exactly that. It will capture any errors that you have in your Pages functions apps and drop them into your Sentry project. So here you can see how I'm mounting this Sentry plugin. I literally just import it. I give it a dozen, which is sort of like Sentry's identifier for who I am and which project I want to put this into. And now this is running on middleware, so it will capture all the requests coming to my page's app and hopefully should capture this through and actually pass it into Sentry. So let's give that a go. Throw an error. Sure enough, this is running local dev. We're getting all the benefits of mini flair with Wrangler to life is good and if we refresh Sentry, we maybe need to give it a second to actually come through. And assuming major networks. Concentrate. Here we go. We got our error 24 seconds ago. So this is hopefully going to help people build powerful things with their Pages functions and in there in their Pages apps. Just by able to by being able to reuse application that shared on NPM or GitHub, we're going to be launching with a whole bunch of official ones and official plug ins for people to just drop into their app. And we've already seen some excellent plug ins built by members of our community. So we're really excited to sort of see an ecosystem grow here. And as always, there's more than happy to take questions in Discord. So if you have any thoughts about plug ins or any of the stuff that we've announced today, let us know there. And I think that's pretty much everything I have to show. So I am going to stop speaking now, stop sharing and encourage you to stay for the next talk. This is from James, who's talking about how they're moving parts of their business onto Pages, I think, from Worker sites and is just going to be talking about that experience and I guess maybe some thoughts on today's announcements or whatever. So yeah, I encourage you to stick around for that and thank you all for watching. I will see you all later. Youtube's customers love our ability to innovate quickly and deliver what was traditionally very static old school banking applications into more modern technologies and integrations in the marketplace. Our customers are banks, credit unions and fintech clients. We really focus on providing end to end solutions for the account holders throughout the course of their financial lives. Our availability is super important to our customers here at COO to even one minute of downtime can have an economic impact. So we specifically chose Cloudflare for their Magic Transit Solution because it offered a way for us to displace legacy vendors in the Layer 3 and their force base, but also extend Layer 7 services to some of our cloud native products and more traditional infrastructure. I think one of the things that separates Magic Transit from some of the legacy solutions that we had leveraged in the past is the ability to manage policy from a single place. What I love about Cloudflare for Q2 is it allows us to get ten times the coverage as we previously could with legacy technologies. I think one of the many benefits of Cloudflare is just how quickly the solution allows us to scale and deliver solutions across multiple platforms. My favorite thing about Cloudflare is that they keep developing solutions and products. They keep providing solutions. They keep investing in technology. They keep making the Internet safe. Security has always been looked at as a friction point, but I feel like with Cloudflare doesn't need to be you can deliver innovation quickly, but also have those innovative solutions be secure.