💻 What Launched Today at Full Stack Week

Welcome to Full Stack Week. Um, so today we're going to chat a little bit about what launched during Full Stack Week on day one. I'm Kabir Sikand. I'm a product manager here at Cloudflare on the workers team. I'm joined by Greg and James. Greg, you want to give yourself a quick intro? Sure. Yeah. My name is Greg McKeon. I'm a PM on the distributed data team, which is Cloudflare R2 and Workers KV and Durable Objects. James, you want to take it away? Yeah. Yeah. I'm James Snell. I'm an engineer on the workers team. Just recently joined Cloudflare a few months ago. Yeah. We're really excited to have you on board with the Cloudflare team, James. So today what we'll do is we'll go through a few of the announcements and chat a little bit about each of them. We'll all ask each other some questions about what the announcement is, who's been using it, why we're building it, and what that means for the community and developers at large. So to get kicked off, Greg, pretty big announcement today around the Durable Objects product that we've been working on over the course of the past year. Could you tell us a little bit about what Durable Objects are and the announcement of the general availability today? Yeah. So I think we could do a whole Cloudflare TV segment on what Durable Objects are. It's open to interpretation, I think, based on how you view them personally. But we're really excited about Durable Objects. We put them into beta about a year ago now. We've been working on them a bunch since then. The basic way to think about a Durable Object is an idea addressable singleton worker. That's the part that you can rewind 8,000 times and try to parse through. So the idea is you write a JavaScript class, and then you're able to instantiate named instances of that class on Cloudflare's network. They look a little bit like a micro-sharded database, because we provide access to a consistent storage API from within them. But you also can write code that executes and controls access to that storage API. And you're guaranteed that that code is running on a single thread in one place on Cloudflare's network. So a great example here is if I wanted to create, say, a game lobby for an online game, I could guarantee that all my workers' requests, despite maybe running anywhere in the world, could forward requests for information about the lobby or requests to join the lobby to one single place, one single stateful place. And we're seeing customers use these a lot with WebSockets and that sort of thing. So it's really a platform for doing coordination and accessing strongly consistent storage within workers. Great. I know that this is often a pretty confusing one for a lot of folks who are new to the workers' platform, but that was a really great overview. We've been working on this for, I think it's been about a year. Is that right, Greg? Yeah. Last birthday week is when they were first put into beta. Yeah. A little bit over a year now. So since then, what's been the focus of the team? What have we been working on? How far has Durable Objects come? What are some of the challenges we've overcome in that time? Yes. I think there's been some features we've launched. So we launched jurisdiction restrictions, which are sort of the ability to do seamless compliance via Durable Objects, where you can tell us Durable Objects start off global, but actually I want this data to only live within, say, the EU. And it's making it really easy for developers to build applications that just comply by default with all these regulations we're seeing coming out. That's been one big feature. We've worked on a few others that have come out. Really, a lot of time has been spent on reliability and performance. So getting the system to a place where we feel confident in it, and we feel confident having our developers or having our customers really build out their own entire businesses on top of that. We have a few customers who have been using this internally. So Cloudflare's waiting room product is built on top of this and doing tens of thousands of requests a second against the system. We're working with some major retailers to support their Black Friday plans on top of Durable Objects. We have a company that built out an entire gaming backend for multiplayer games on top of Durable Objects, seeing a lot of demand from companies building out sort of like real-time collaboration use cases. So interactive whiteboarding apps. And that's really exciting to us. And we have the product at a point now where we have customers who have been running in production, and we feel confident sort of opening it up to anyone who wants to take a whack at it, I guess. And then we have plans for features that we're going to continue to build. And we have a big focus on performance and the ability to do replication with Durable Objects. So I mentioned that Durable Objects run in a single place in the world. Sometimes if you want to scale up reads, just like you'd take a database and deploy out a read replica that can handle some of that traffic, people want to do that with their Durable Object, where they can't actually mutate the state inside of it, but they can scale it out by running multiple read copies around the world even. And so that's a big piece that we're working on now. We also laid out in our initial beta blog post kind of a vision for migrating these Durable Objects for low latency to be close to end users. We're working on our designs for that and figuring out what that might look like down the road. Another big feature that's going to land relatively soon is Durable Object alarms. And that's the ability to wake up a Durable Object reliably. And this is a pretty key building block for things like queues, where you might not have a request come into the system to wake the Durable Object back up and trigger it for a while, an HTTP request. So the ability to reliably say, hey, 30 seconds from now, check to see if this object has any work to process. So we're pretty excited about that and that that's coming along. That's great. It's definitely come a long way, just kind of seeing it from the inside being built. It's exciting. Do we have any major customers or use cases that have come out in the past few, I guess, months since we've kind of been doing the data for this? Yeah, definitely. So it's really big on that sort of coordination, collaboration type use case. We're seeing a lot of people connect WebSockets in and build out applications on top of WebSockets, where they're actually terminating the WebSocket connection in our runtime and building up the application on top of us. We've seen that gaming use case, a lot of retailers looking at this as well. I think it's really a good fit for both large enterprises that sort of want to iterate more quickly. One of the great advantages of Durable Objects is there's no infrastructure to manage. So we've seen them replace Node.js, I'm sorry, James, for a few use cases, where customers didn't want to manage containers and have to handle scaling and all that kind of associated complexity. And they were willing to kind of go with the runtime for that. So that was a big part of the gaming use case I mentioned, which is, you know, when you're building out game servers, you want them to scale, turn on instantly, right? And then when the match is over, you want to turn them off and scaling that up in Kubernetes can be a real bear. And so they saw a lot of wins there on the infrastructure side, but also on the developer productivity side. So I think that's the general sort of layout, lay of the land of who's using them. And it's also people are building their companies on top of them. So I think we have another Cloudflare TV segment later today that's going to be, you know, on a startup that's building on top of us and really using them as their sort of competitive advantage to move faster than their competitors. And I think that's a really exciting story. And, you know, we've talked a lot about wanting to build the next billion dollar business on top of workers. And I think that's becoming more and more of a reality as we put out more of these primitives. So that's exciting. Yeah. Exciting places, exciting place to build. So durable objects now generally available on the Cloudflare platform as of today. Another announcement that we made today is a partnership with MongoDB and Prisma. Again, back to you, Greg, on chatting a little bit about that. What was the demand there? What was kind of, why did we go and do that? And what are some of the use cases? Yeah, definitely. So Mongo and Prisma joined kind of our existing database partnerships with Fauna and Macrometa from last year. I think really our strategy here is around, you know, looking at what data products developers want to use and what is already well aligned with sort of the workers platform at the edge. And so MongoDB, we did a survey. MongoDB was, I think, one, number one or number two, most requested integration. Really easy to set up and get started and then scales beyond that. I used to work at Mongo, so I definitely know the marketing material there. But really easy to get started with, just like workers, really easy to set up your application and then easy to scale it as it grows too, right? And so the ability to kind of start on day one with something and keep that in your architecture the whole way up, I think is really appealing to people. And so we integrate directly now with MongoDB Atlas. MongoDB put out a small little tutorial on how to do that and connect through that's over HTTP. So it integrates with their Realm driver to connect right into Atlas. And then on the Prisma side of things, Prisma has built out a data proxy layer that lets you take HTTP connections and proxy them back to a number of backing databases. If you're not familiar with what Prisma is, Prisma is an ORM, sort of a modern ORM that's designed to abstract away the data layer. So you're not issuing raw SQL queries to your backing database. They also support MongoDB, so not necessarily raw SQL queries, but the ability to sort of define a consistent data layer that works regardless of the back end that it's actually pulling against. Really powerful, really beloved by developers, again, just like Mongo. And it just reduces a lot of the headaches that I've seen people run into when developing their apps. And I think this sort of idea of you have a large number of databases that are in your infrastructure and we present some abstraction layer over them that your application actually interfaces with is really exciting for us to work with. And so when Prisma came out with their data proxy, we love the team at Prisma. We chatted with them about that and we built up this integration. So this is a great way to take workers and connect back to MySQL or SQL Server or Postgres or MongoDB, if you're willing to kind of go through that query language and to go through the data proxy via Prisma. So really excited about both of those and they really fit well with workers. Yeah, certainly excited as well. On the partnership side, what's kind of the general thinking about partnerships with some of these types of providers? Yeah, so we're at four now, right? And so I guess there's kind of a strategy developing here. And I think what it comes down to for us is sort of a broad strategy that even applies to how we see R2 entering into the marketplace, which is we really want developers to be able to pick the solution that's best for them, right? We don't want them locked in by egress fees. We don't want them locked in because they're on a specific provider or another. We want them to be able to say, hey, my data, I want my data in MongoDB. I want my data to be accessed through Prisma. I want my data in Fauna. I want my data in Macrometa. I want to be able to use the tools that fit my use case the best. And that's what we're going to enable with workers. So that means dropping egress fees, but it also means partnering with tools that developers love and demand access to, to just help them do that more easily, right? I think that's something that's become more and more difficult over time. It's actually getting the data to the tool that you want to use. And we really want to change that. And so I think that's a big part of the partnership. Yeah. So broadly, a lot of what we've announced today in general is really in the data realm. So next thing that we will talk about is about support for relational databases using database connectors. So I can chat a little bit about that. Basically, we've decided that coming in line with this story that you've just painted, Greg, there's data kind of everywhere. Developers need relational databases for many, many use cases. Cloudflare itself is built upon relational databases. Many, many of the most popular products today still utilize that model. And it's growing in popularity. If you look at some of the database statistics, some of the top four databases are relational databases. And we don't really want to necessarily force our customers to have to migrate that data over to yet another provider. So our theory with building database connectors, we're starting with MySQL and Postgres, was let's figure out how to connect to places where our customers are already storing their data. And we're really just beginning on this path. This is ultimately the first step. And so we've built a tech demo that any of our customers can go ahead and use right now. We're utilizing a Cloudflare tunnel, communicating over a WebSocket over to your infrastructure. You just have to spin up a Cloudflare tunnel called Cloudflare D. On that infrastructure, for our tech demo, we put pgBouncer behind it and put up a Postgres instance behind that. We also have a tutorial with some sample data that you can use to seed that database. And then directly from your worker, you can use our driver. And I actually should rephrase that. It's not our driver. We took a driver off the shelf from a growing community over at Denno. And we just shimmed it a little bit. A little bit of an adaptation to work on the worker's platform. And right out of the box, you're basically able to just run one command and utilize a really exciting driver from the folks at Denno and just issue queries directly to your database from your worker. So it's a really great first step. If you guys are out there and you're looking for use cases, you want to try out some data that you already have on some of your own infrastructure, feel free to take this for a spin. It's a great place to just get started building applications on the worker's platform and connecting the data that already exists out there. As you're going through the explanation of that, talking about connecting the data where it exists or having to modify the driver to get it to work, it's fantastic that we're able to do these things with the existing platform. But it'd be better if we didn't have to modify those drivers. If things work consistently from Node and Denno and workers that we get access to that data in a consistent way. Yeah. Agreed, James. I think that helps bridge the gap a little bit over to one of the other announcements that we made today that you really drove a lot of, James. So some of the limitations of our approach with WebSocket and a Cloudflare tunnel will start to show itself if you try to use this at extreme scale. One thing that James just brought up is there really shouldn't be a need to modify a driver. We should be able to just communicate directly over from a worker to any sort of socket type of protocol. We don't necessarily want to install a Cloudflare tunnel on our infrastructure. In some cases, you can't. So it's not, as we said, it's really just the first step. And what James has started to work on is really a standardized socket API that can be used across a lot of these different providers and communities. So James, why don't you talk a little bit about that? What exactly are we doing and why are we doing that? Yeah. So you framed it perfectly there. In terms of defining what this socket API is going to be, how do we actually build modules that can open these connections, go back and talk directly to the infrastructure without having to tunnel it through WebSockets, without having to really tunnel it through anything. It's just raw TCP connections or eventually quick connections, those kinds of things. It'd be really fantastic if the developers that were building these drivers for the databases didn't have to care about what platform they were going to run in, what environment they were going to run in. So they write it once, and it's going to run a node, it's going to run a DNO, it's going to run in workloads, wherever else. It's the same consistent set of APIs across the board. It goes back to the point that Greg was making earlier. So we don't want to lock people into any piece of the platform. And if somebody's writing an application, that should be able to be distributed on the edge or backend or whatever, and still be consistent in how those pieces are developed. So that's really what we're looking for with this. Hopefully, some of the other platforms will get involved. If I am involved in the community, I'm a developer who wants to see this happen, what can I do to help out with this process, or how can I get involved into the conversation? Reach out. In the blog post, we have a link in there for signing up if you're interested in using this eventually when it's delivered. If you want to help develop and work on the actual API standard, connect with me directly. I'm easy to find on Twitter, just JASnow on Twitter. Just reach out to me, and I'll point you in the right direction. We have a GitHub repo where all of this work is going to be happening, at least for the definition of what that standard is. And I want to be clear, it's not just client-side connections. One of the things we talked about in the announcement today was the thing called Socket Workers, which is the ability to talk to a worker over non-HTTP protocols. So open up a TCP connection or a quick connection using some other protocol that's not HTTP, and still be able to interact with workers and durable objects and that kind of thing. Ideally, that API that we're defining for the client-side will also work for the server-side, not just in workers, but also these other platforms as well. It's amazing what I think a lot of these various platforms can do when we come together and kind of define a standard. So excited to see the road ahead for this particular project. Yeah, it's going to be very interesting. So far, we've already had some fantastic feedback from the community, folks asking, what kind of stuff can we build with it? And we're like, we don't know yet. You let us know. You can do all kinds of stuff with it. But I'm excited to see where it goes. Yeah. So by the way, just kind of to wrap up everything that we've been chatting about today, big focus on data, big focus on what's the future of connecting to non-HTTP applications on Cloudflare using workers or connect to workers over other sockets. If you're interested in any of this, go ahead and head over to blog.Cloudflare.com. You'll see a few of the blog posts that we've posted today. In all of them, there's a form that you can fill out if you're interested in working with us, if you're interested in getting access to things like the database connectors. We have tutorials that are spun up as well for Postgres. Our current tech demo also works for MySQL. So it'll be a very similar process to what you see in that Postgres tutorial. And if you want to hop into the conversation, there's links within all of those blog posts to hop into our Discord. We have a very active and growing community there. And if you want to be a part of that conversation, feel free to join. James, Greg, anything else to note or to touch on before we wrap up today? I think the last thing is a plug for if you're interested in these enhancements and want to come work with us and help build more of them to reach out, for sure. We're always looking for people. Yeah, I'll just second that. Particularly if you want to help with developing the Socket client stuff and the server-side stuff, our team is definitely hiring. That is definitely one way, so reach out. Sounds great. All right. Well, we're going to wrap up today, and we'll see the rest of the community tomorrow for another episode of what we launched today at Fullstack Week. Have a good day, everybody. Bye. This video will show you how to get started with Cloudflare Gateway by configuring a location, creating a policy, and using that policy to block security threats. To get started, navigate to the Cloudflare Gateway dashboard at dash.teams .Cloudflare.com. If you don't have a Cloudflare account, you can sign up, and the browser will redirect you back to the Gateway Overview page. Now, let's configure a location. A location is typically a physical location, like your home, office, store, or a data center that you'd like to protect. For this demo, let's call our location aus-1. Gateway should automatically detect your IP address, which allows Gateway to know which requests are coming from your location or network. Now, let's configure the DNS resolvers. To take full advantage of Cloudflare Gateway, you should change your router settings to the Gateway IP addresses. For this demo, I'm only going to use the IP addresses that Gateway assigns. Now, let's configure the DNS resolvers. To do this on a Mac, go to your laptop's system preferences, click Network, then Advanced, and navigate to the DNS tab. You'll see your existing Internet provider's DNS server IP address here. Add in the IP addresses from the Gateway dashboard by clicking the plus sign. If your network supports IPv6, make sure to add the IPv6 address here as well. Click OK, then Apply. Now, my laptop is sending all of its DNS queries to Gateway's DNS resolvers. To complete the location setup, navigate back to the Cloudflare Gateway dashboard and click Complete Setup. After configuring your first location, you'll see the Gateway overview page. Here, you can view your location's requests and if they were allowed or blocked. After the initial setup, the graph may take a few minutes to show data. While we're waiting on the data to populate, let's confirm that our location was properly configured. It looks like our location is properly configured, but as you can see, there's no policy assigned. Let's create one. Create a policy and apply it to your location to protect your network from Internet security threats like malware and phishing. The policy will control what the user can or cannot access while connected to your location. To create a policy, click Policies, then Create a Policy. For the purposes of this demo, I'm going to create a policy that blocks malware and social media. Let's call this No Malware or Social Media. We'll assign it to our location by clicking here. Here, you can enable a blocked page, which will show if a user attempts to access a page that's been blocked. Let's enable it, then click Preview to see what a blocked page would look like. Let's disable it for now. You can also enable Safe Search, which allows Cloudflare to automatically filter content based on the same restrictions that large search engines use to protect users from explicit content. Now, let's identify what security threats we want Cloudflare Gateway to protect against. Gateway allows you to block all security threats listed here with one click, which include malware, phishing, and spam. Let's just block malware and social media. Then move on to the content categories. Gateway allows you to block certain content categories. Since we want to block social media with this policy, click Society and Lifestyle, then Social Networks. If you'd like to allow or block a specific domain, you can do that in the Allow Block tab. Let's enter chatgoogle.com to ensure that it's blocked and click Add Domain. Now that the policy has been configured, let's click Add Policy. The policy will propagate throughout the Cloudflare network in a few seconds. So in the meantime, let's check out the Gateway Activity Log. The Activity Log is where you can see all the requests to your configured location. You can also see what content categories the requests were associated with. This request was associated with content servers and information technology content categories. It was an HTTPS request created from the AUS-1 location and was allowed as it didn't trigger the policy. Now, let's test our policy to make sure that it works properly. Let's test the social media portion of our policy by attempting to navigate to Twitter. Shortly after hitting Enter, you'll see an error page indicating that Twitter cannot be reached. Cloudflare Gateway has successfully intercepted the request and blocked the page accordingly. During this Cloudflare Gateway walkthrough, you saw how to configure a location, create a policy, and use that policy to block Internet security threats. To learn more about Cloudflare Gateway, navigate to teams.Cloudflare.com backslash gateway. Hi, we're Cloudflare. We're building one of the world's largest global cloud networks to help make the Internet more secure, faster, and more reliable. Meet our customer, Wongnai, an online food and lifestyle platform with over 13 million active users in Thailand. Wongnai is a lifestyle platform, so we do food reviews, cooking recipes, travel reviews, and we do food delivery with Lineman, and we do POS software that we launched last year. Wongnai uses the Cloudflare content delivery network to boost the performance and reliability of its website and mobile app. The company understands that speed and availability are important drivers of its good reputation and ongoing growth. Wongnai also uses Cloudflare to boost their platform security. Cloudflare has blocked several significant DDoS attacks against the platform and allows Wongnai to easily extend protection across multiple sites and applications. With customers like Wongnai and over 25 million other Internet properties that trust Cloudflare with their performance and security, we're making the Internet fast, secure, and reliable for everyone. Cloudflare. Helping build a better Internet.