💻 What Launched Today - Wednesday, May 17

Hello, hello, hello everyone and welcome to day three. That's right, day three of Developer Week 2023. And today I am joined by esteemed guest Nevi Shah, Product Manager for Cloudflare. Also Igor Minar, Senior Director of Engineering and Greg Brimble, Systems Engineer with Cloudflare. Welcome guys. Welcome today. How are you feeling? Feeling great. Yeah, let's do this. Good, good. Well, today we had a few announcements launched today, and I'm really excited about many of these announcements. So take it away Igor, what we launched today? Too much, but a lot of it is exciting, super exciting for me, but also I know for developers because Nevi and I spent the last two weeks out there talking to developers and kind of previewing these announcements and we hear that the announcements resonate really well with developers. So what is it that we've done? The big one is that we announced today that we are merging Cloudflare Pages and Cloudflare Workers into a unified development platform. And this is huge. And Nevi, do you want to take over? Why? Yeah, of course. Why? So I feel like, you know, as a PM, I talk to users a lot of times and a lot of these, a lot of the feedback that we get all the time with Pages and Workers, especially when users are starting is, what's the difference? Like, when do I use one over the other? What is one good for? What are the trade offs I'm going to make if I choose between Pages and Workers? Pages and Workers by nature are similar products, right? The way it was explained to me is Pages is kind of like that funfetti cake mix, the bring it yourself, you know, everything's all ready to go, pack it together. But Workers is more of like the, you have the flour and the sugar and you kind of bring everything together yourself. That didn't make sense, sorry. One is more DIY, one is more opinionated. And so, but the goal is the same, right? The goal is to build serverless applications. And for us to kind of bring both forces, Pages and Workers together, bring the best of both worlds together, we're actually creating one super powerful platform, right? So imagine a world where you don't have like the static assets platform and you don't have this separate serverless functions platform, but instead you have one platform and you have this idea of a project where you can bring your static assets and your serverless functions and your resources all in one place. You don't have to poke around in different parts of the dashboard to find this project. It's all in one area. And I think really, it's like we want you as developers to come to Cloudflare and really just figure out what you want to build. You don't have to choose what product, you don't have to worry about the trade-offs that you're going to make. You don't have to worry about managing two different products and their pricing. It's going to be one product, one experience so that you can just focus on what you do best. And I'm really excited about it. I think also from like a nerdy engineering perspective, it's really exciting to be able to bring the teams together, to have one code base, which isn't, you know, a reason why we're doing this, but I think it's a really important part and it's good in development practice. So I think really excited about this. I think it's still very new, very in the works. We had a first milestone that we launched today, which is we're merging parts of the dashboard. So you'll start to see that pages and markers will show up frequently on similar screens. When you create a project, we have templates, which are really exciting. And so I think this is a really great step in the right direction. And I think we're really looking to the community, to our users, our customers for feedback on what they're expecting. We don't just want to merge these products. We want to create a really stellar experience and we want your help. We want to know how is this platform going to be best for our customers. So really looking to hear your feedback. And I think in my blog post, if you read at the bottom, we have a survey that we are launching to kind of get to know our users a little bit better and get to know, you know, what are your expectations and what are you looking for? Awesome. Exciting. I can't wait to see how we can do more with these two big products merged into a single one. I do think that it's going to make it much easier to build the existing kind of applications, but also future generations of applications that I expect will be heavily influenced in how we build full stack applications today. And we also had a very relevant announcement for full stack applications. I think we started talking about it yesterday and we are reinforcing and double downing on it today. And that's related to smart placement. Smart placement is all about how we enable you to build better full stack applications and how to do server -side rendering from our WorkerD runtime, how to integrate that into CDN. Greg, do you want to take it away and tell us a little more about smart placement and Pages and how it all fits together? Sure. Yeah. So, I think, like what Nevi was saying, the whole idea of converging Workers and Pages together is that you get all of the powerful pieces that you can get today in the Workers platform and all the future ones. But Pages gives you just the simple managed workflow, at least at the moment. So we're going to continue to offer that. But one of those useful and cool components that we're developing at the moment is this concept of smart placement. So, to date, when you've been deploying things to Cloudflare's network, it's been mostly to the edge. We've served this content from all of our locations around the world. And that's great for a lot of apps that you build. If you have something that you're able to just immediately return, there's no sort of data to render or anything like that, then it's perfect if it's just a static site. Ideal. But as soon as you need a point of coordination, if you've got some maybe external service that you're relying on, like an external database, or you're integrating with some other third party, then perhaps they aren't as global as Cloudflare. And so you need to be able to have quite a decent conversation with this particular location. And that's what smart placement is hoping to solve. So the way that it works is your visitors, wherever they are in the world, they can connect to Cloudflare, to its nearest location, but then we can reroute your app to run in a location that is optimized for where these conversations are happening in this particular region. And that means you're really minimizing any latency that you would get in an otherwise lots of round trip conversations. So the hope is that we're able to render your applications a lot faster because of this. And the really cool thing about it is that it's smart. So you can turn this on, and we're only going to actually take action here, we're only going to move it to this location, if we detect that it's actually going to make an improvement to your app. Otherwise, it's just going to stay at the edge where it is. And so I think we're, we've started off with some heuristics, where we're watching like the connections that you're making from within your, your app. And those might change. And we'll sort of evolve what analytics we can show you and really give you insight into exactly how your application is running and where it's running. Cool. You mentioned a lot of interesting buzzwords. I did, yeah. Edge. Do we have an agreement of what is edge? Because I see a lot of passion and discussion in the developer circles about the edge. Is it a runtime? Is it a location? What is it? What's your take? The edge, at least to us, is sort of the concept of running things near to users. So for us, we have this global network with 200 plus locations around the world. And so when we say edge, what we mean is the nearest location to the user, basically. And so in my case, I'm in London, I can connect to a data center in London and get back a response really quick. So like I was saying, for static assets, that is perfect. And but if I had data around in, let's say, the States, I need to make a request all the way over there. It's 200 milliseconds or whatever. And if I need to have a conversation with it, I need to bounce back and forth. And that's really costing me for the performance of my app. The smart placement lets me move the compute, the bit of my app that does this rendering over to the States, have that conversation with the database or whatever it is, and then deliver the final result back to me so that we don't incur that 200 millisecond cost over and over again. We just get it that once there and back that we need. Right. So edge is a location, but it's not a specific point in geographical location, it's virtual location. And it's like a deployment target where you could put some, some things. So it really means like the closest data center that we have near where the user requesting the application is, that's the edge. So with Cloudflare, 285 data centers, which just got updated. I said last time I checked it was 285. I was like, that's a new number to me. I know. I just, I just checked yesterday and then we bumped the number to 285. So 285 data centers around the world. And all of, all of them could be the edge, but all of them also could be the location for smartly placed application because they could be the data center that is the closest data center to data. So depending on the application needs, if it's talking to a database a lot or some kind of backend a lot, then we'll smartly place it to one of these locations, wherever the data is. But if the application is not talking to data, if we are just static, serving static content, or if you're doing, if, if data is already at the edge, then we can actually perform the computation, server side rendering, whatever it is, near the user. Can you talk a little bit more about, I think this is a really interesting part that not everyone realizes. Talk a little bit more about like the server side rendering aspects of it and like why this is so huge for like the framework world. So for, for some time, people have been already deploying full stack applications to pages, Cloudflare pages. And what full stack applications allow you to do is by definition, they span the client side, as well as the server side. And on the server side, you don't only do API, serve API requests, but you also often do server side rendering, which means you pre-render or render the application on the server side into an HTML that you shoot over the wire to the browser. So the browser can quickly display something. And then once the application is displayed, the screen is displayed. Depending on the framework that you're using, we either hydrate the view or resume it. And that's how you have the application displayed and interactive in the fastest time possible. So with smart placement, without smart placement, you could use pages to deploy application. But there was a, there was a issue. And the issue was that we always did server side rendering from the edge, the virtual location near the user. And that might have not been the best place to do it because many server side applications that do server side rendering actually need to talk to the backend multiple times. They need to make several queries to fetch the data so that they can actually render the screen that we are trying to display. And if the rendering is happening at the edge, then, and the database is far away from the user, let's say the user is in San Jose, California, but the database is in Germany, Berlin. Then we instantiate the application in San Jose, because that's where our data center is. And that application from San Jose is talking to a database in Berlin, Germany, going over the ocean, super high latency. Now we need to make five requests to fetch all the data, takes forever. Not a great experience for the end user. With smart placement, the same application, you just toggle switch. And now the same application will start observing and determine that the data is in Germany and applications should therefore execute on the server side in Germany. Will just happen to execute in Germany without developers having to do anything. The user will still connect to the data center in San Jose. Any static assets will be served from San Jose because that is the fastest location to serve static assets from. But any kind of API calls or server side rendering invocations will happen in Germany, probably in Berlin or thereabouts. We're near where the data is and users don't have to do anything. I think I just think it's so cool. And one thing I really wanted to point out is if you haven't seen this already, there's a demo that I think Mark Miller put together that really demonstrates like the visual of, okay, your data is here, your user is here, your application is up here. And I think just kind of seeing the visual of like, if you changed your database to here, your compute here, this is how fast your application can be. I think the demo really just brings it to life a little bit more. So I definitely recommend checking that out. It's all over Twitter. Smart -placement.pages.dev. Smart-placement-demo.pages.dev. That's it. There you have it, folks. So okay, then speaking about all these full stack frameworks, Igor, talk a little bit more about like what your team has been up to on putting some really great support for these full stack frameworks in our new CLI. Yeah, so we have amazing infrastructure to build applications, but that is not enough. In order to make it possible for developers to build these applications. We had to choose. We could either build a framework of our own and convince everybody to start building applications in the Cloudflare specific way, or we could have gone out there and meet developers where they are and make sure that existing frameworks work really well with Cloudflare. And we did the latter. We collaborated with teams across the industry, starting with Angular, Astro, Quick, Remix, Solid, I don't know, TooMany, Vue, Nuxt, TooMany, I'm sorry if I'm missing somebody. And we made sure that all of these frameworks have very good integration with Cloudflare. A lot of the fixes have landed and things are great. In some cases, there's bigger things that need to happen on the framework side, and we're working with the teams to actually get that done. A big discovery during our research was that server-side rendering works better, especially in serverless environments like Cloudflare, if it can take advantage of server-side lazy code loading, which we often do on the client side. Most of the modern frameworks do lazy loading on the client side, but on the server side, most of the assumptions today have been around like, oh, on the server side, lazy loading doesn't matter that much. It actually does. It speeds up how quickly the application can start rendering. So we're working with the teams across the industry to make sure that all of the frameworks are doing lazy loading on the server side. Some of them are already there. I think Solid and Quick are excellent. I know that others are committed to doing it. I talked to Remix. I talked to Astro. Angular is already doing it. And we're working with the rest to make sure that we also support it. So, yeah, we have all these adapters. And in addition to adapters, we also launched a very nifty tool that allows you to get started. Greg, maybe you would like to talk about that one. I think you're intimate. I mean, I can start off and then you can add to it. Yeah, I guess the biggest thing that we want developers to be able to do, like Igor said, is we want to meet them where they are. We don't want vendor lock-in. We don't want to say, hey, this is the framework you have to use on our platform. It's the only one that works. We want developers to be able to choose whatever kind of framework they want. And to prove that, we wanted to really have developers get started as fast as possible. So, Igor's team has been working really, really hard to come up with this brand new CLI that basically integrates directly with these frameworks and kind of creates this really wizard -like experience. So, you start off, you talk, you choose what kind of application you want to deploy. It could be a worker. It could use a full stack web framework. And then we have a list. I think there's like, what, a list of 10 or 11 or 12 frameworks that you can choose from. And then we actually talk to that framework's CLI, and everything that you see is what Remix or Quick or Next or Nuxt actually has put forward. So, it's a really cool experience. You can get an application. You can go from idea to deploy in like, what, maybe a minute. And it's a really, really cool way to just see the power of pages plus these frameworks. And I think the command is npm create-Cloudflare. So, definitely give it a try. Igor, what else do you want to add to that? We can try to demo. I have not tried to do demo on a Zoom call, but we could definitely try. Should we? Or no? Yeah, can we demo stuff? Leroy? Oh, no. I don't have my computer set up to... No, but if there's a link to the demo... Yeah, okay. We'll link the link. Yeah, there's a little demo in my blog post and I think in Igor's blog post as well. It's super cool. I think also it's just meant to show the power of the platform and we're going to continue to increase support for different frameworks for this as well. Yeah. So, to get started, just npm create-Cloudflare. If you're using Yarn, you can do yarn create -Cloudflare. pnpm also works. So, pnpm create-Cloudflare. So, npm create -Cloudflare and you're ready to go and you'll end up with a deployed application very quickly. I've been building applications for 15, 20 years now, but I don't think I've deployed as many applications in the span of a week in the last week compared to everything I've done before. It's just so easy to build. Yeah, I was going to say that's a testament to how easy it is. You can go from nothing to deployed application in literally a minute. And that's super, super cool. So, if we see a spike in usage, then that's your fault, Igor, then? It's not my fault. It's my credit. Credit me, yeah. You're a bonus me. Exactly. Yeah, this is my favorite day. I think we all work on the experiences team and I think developer week we've had a lot of really great announcements around AI and database or data stores. But I think this is a really exciting day because we always want to talk about how we're trying to improve the experience. It's definitely, I know, something that we get asked about a lot. We get heat for a lot. And so, it is a priority of ours and it is something that we're working hard to improve. So, all of these kinds of changes that we're making are all with user feedback in mind. So, really excited about this day. I think we got a lot of really great reactions on it. So, excited for everyone to kind of check out the blog posts and tell us what you think. Yeah. Let's talk about a few more things because, again, we launched so much. We're not going to be able to even cover everything that we launched today. But very quickly, we announced that we will be increasing memory CPU and application size limits. The actual change is going to go out within a week or so. We just need a little more time to wrap things up. But the goal there is to enable developers to build bigger and more sophisticated applications. We see that the full-stack applications today, they're pushing the boundaries and hitting the limits, the current limits, especially deployment limits. Because a full-stack application can easily be multiple megabytes of JavaScript once deployed. And we saw that in order to make it possible for developers to be successful, we need to increase these limits. So, we're bumping the application size to 10 megabytes after gzip. So, that's what you'll be able to deploy to us. We're also increasing the script compilation time limit. That is the time that the application needs to be able to start become responsive within. Currently, it's 200 milliseconds. It's going to be 400 milliseconds. There are additional changes focused on increasing memory usage and available memory. And also, we're making some changes, exciting changes to pricing. And I believe there is a blog post scheduled for later in the week. So, I'm not going to spill the beans on that one. But there are two more things that we should discuss on this call. One is the improvements to the local development environment. And secondly, the changes we are making to a CI environment. Maybe Greg could jump in and tell us more about the build image and the CI. Yeah, certainly. So, as we know, workers and pages are converging. And so, we imagine that in the future, we might have a place where we have a whole lot more people using the pages CI. So, maybe we get workers building on there. And that's just the way to deploy full stack apps. Maybe. You're definitely going to get workers building. Fair enough. But the point is, it's high time that we update the image that we had. So, pretty much, it remained constant since pages launched like two years ago. I think we literally just had its second birthday. And so, we know that a lot of the tools and languages that were in that image to start with are now quite out of date. So, we've launched a version 2 beta that is available to try today. You can go into your pages product settings and turn this on. And with that, you get the updated set of tools and languages. All the classic stuff that you'd expect, like Node 18, Python 3. And then, we've also sort of done a lot behind the scenes to make this not only easier to keep updated in the future, but also to pave the way for new features that we all want everyone to be able to take advantage of. Like I say, as we onboard workers to be able to use this system if they want. And, yeah, just really take advantage of the whole ecosystem that we have going with Git integration, preview deployments, all this sort of stuff. So, one of the big things that we did was sort of break things down. Everything was one big monolithic environment. And we would do absolutely everything in it. We would clone the project from Git. We would install all of the tools and languages. We would run the user's build command. And then, we'd do the upload. And that was all taking place in one place, not to mention streaming logs. And now, we've sort of broken it down into three isolated containers. So, that gives us an advantage that makes it much easier to just sort of swap in new ones as we want to keep these tools and stuff up to date. But also gives us an extra layer of security when running a user's builds in one well-locked down place. So, like I say, lots of advantages. Is it going to be easier for us to shut down all the Bitcoin miners and crypto miners? Yeah, well, we'll see. We'll hope to be able to offer good integrations with a lot of the projects. So, one thing that we're looking at is build caching. So, we're going to be able to see like what dependencies you have in your project, what you're running. And so, we get a really good insight into what it is you're doing in the building. Perhaps some people are using our infrastructure. You've been put on notice. But, yes, it helps us. And then we're able to use that same infrastructure and tooling and stuff to help support our users with features like build caching. So, yeah, this is sort of just the first step in the direction of really solidifying this infrastructure for, like I say, hopefully a whole bunch of users using it in the future. And regular maintenance going forward. Sorry, I just want to say, like, I think on Pages, we have a lot of users, right? We have folks who really care about what their build system is doing and folks who literally don't care about it. And so, we really want to provide an experience that like you have the optionality to pick your build image. But also, if you don't want to, then you don't have to worry about it. So, I think, you know, Greg and the team have done a really good job of kind of managing those two situations. So, yeah, if build image and build systems don't interest you at all, don't worry about it. Yeah. Exciting. I think this is going to be very important as we expand, as we converge Pages and Workers because CI is an important part of the workflow. And eventually having it available for Workers as well and not just for Pages is going to be super cool. Speaking of Workers, like one of the pain points with Workers has been development and especially local development. Where previously, if you wanted to build a Worker, we used Node. We built a custom emulator of our production environment that was based on Node. But in production, we don't run Node. We run a much more lightweight runtime we call WorkerD, which is a customized V8 runtime. And developers could tell because when they tried to build anything locally, it would not always completely reproduce the issues in production. And sometimes things that work locally would not work in production. It was very frustrating. But we fixed that, right? Neri, would you like to talk more about that one? Nope. I can take it. That's okay. That's okay. Well, we did fix it. So, one of the announcements today is that Wrangler v3 is released. And I know that this might sound scary because it's a major version, but it's really good old Wrangler v2 with a few small but significant changes. And one of the changes is that by default, when you run Wrangler dev, you will be using local development environment powered by WorkerD. So, the same runtime that runs in production is now going to be fully integrated and by default available to you in all your development workflows. This is super exciting. It's going to make development debugging much easier, much easier to reproduce production issues. Additionally, we made a few additional changes. We updated dev tools. So, if you want to debug your application, you can use Chrome dev tools that are customized for WorkerD. You can see all the sub requests. You can profile CPU, profile memory usage, all of the things that you would need for sophisticated applications to tune in sophisticated applications. And last big change that I want to highlight on this call before we wrap up is we also launched a new editor. Previously, you could go to Dash and edit your simple Worker applications using a built-in Monaco editor. That would serve us well for a couple of years, but we always felt like very limited that it didn't support type checking. It didn't support editing multiple files. It didn't support some of the features that we wanted. And one thing we are launching today, one of the many additional announcements is that we are replacing the Monaco with VS Code. This is in the Dash today. So, if you go, you can edit the application. We're going to spin up VS Code in the browser, fully integrate it, and the editing is going to become much more powerful. There are still things that will not work. For example, TypeScript support is not there yet, but it will come over time. I think, sorry, I spaced out for a second. But one of the things that's really exciting about these announcements are just like the removal of friction. I think getting started and having like testing in your staging environment and then having it not show up the same in your production environment is super frustrating, right? So, I think the fact that all of these announcements, the build image, the quick editor, the local development experience, really is just we're trying to remove that pain. We're trying to get you to deploy as fast as possible. And that's what our team really works on. That's part of the experiences team in general. So, I think that in addition to all the shiny and great announcements that we have this week in the first few days, I think these are the announcements that really, really matter to us and that we want to continue to work on. Well, I want to thank you guys again for joining us today and letting us know what was announced and what was launched today. We have roughly about 30 seconds left. So, if you have any last comments to share with the developer community, please feel free. I will very quickly jump in. In one hour's time, we're going to be hosting a Q&A in Discord, the Pages team. So, we can chat about any of the announcements in further detail and you can ask any questions that you have for the team. All right. And be sure to visit us on Cloudflare.com and check out all the announcements. Thank you, guys. Thank you so much. Thank you.