Developer Week Day 2: Fullstack on Cloudflare

Hello everybody and welcome to Developer Week Day 2 live stream. We are so happy to have you here with us and I am so incredibly happy to announce my co-host today, John Resig. John, when I thought our mission, our mission here at Cloudflare is to help build a better Internet. And when I think of people who have helped to build a better Internet on the developer side, man, there is nobody, there is nobody more than you that I, that I can think of. And I just want to first, I want to gush. I'm going to gush a little bit. We've got a little bit of time here. I just want to say thank you. Thank you on behalf of all of us who have jobs in the web development space, especially coding JavaScript. I want to say thank you. You're welcome. Thanks for having me. Yeah, I think the, yeah, I mean, it's, it's an honor, but yeah, I'm, I'm, I'm glad I was able to help make the web a better place. Yeah, I mean, I mean, absolutely. And I, I think I would like to take some time because I've been talking to some friends. I was like, oh my gosh, I have John Resig, the creator of jQuery, like the creator of jQuery is going to come and talk to me. And I, and some people didn't know what a big deal that was. And I was like, oh, I guess, I guess my gray beard's showing a little bit right now. And I want, I would love if we could take just a little bit of time and bring it, and this might be painful for you, but I want, I want to go way back to the start of this, to the start of jQuery and how, how that happened. How, how did that, how do we get started there? And let's go, let's go first. Let's talk about what was happening on the Internet at that time. What did it feel like to build a JavaScript application or JavaScript? Yeah. So I was building jQuery initially back in 2005. And at that time, that sort of peak, what was then Ajax, you know, kind of era where people were making, you know, started to really make dynamic sites that, where you could do network requests that didn't require a full form submission essentially. And I was making a number of different applications. I was actually still in college at the time and I was just, you know, building stuff. And I think there were a number of things that annoyed me as a developer, which was back then browser incompatibility was a much bigger deal than it is nowadays. Just basic, basic APIs diverged in baffling ways. And that was one immediate problem where if you wanted to build something at just a basic level, you had to have ideally some sort of, at least API on top. Yeah. Yeah. Yeah. Right. Because, because all the different browsers, like what browsers are we talking about? Like let's, let's break, let's break there too. At that point, it was IE 6, IE 5.5 for Mac, Firefox 2, I believe. And I'm trying to think there would have been, this is pre-Safari, pre -Chrome. I think it's pre-Safari. I can double, my dates are a little fuzzy here. Then Opera. Yeah. Yeah. Yeah. So that's just kind of the, the landscape there. But I think the, yeah, it was just complicated. And. And everybody did it different, right? Every single person did that different. So, so it was like, if you had to do that by yourself, 60 lines of if statements. Right. I mean, maybe, and it does require a ton of cross browser testing as well, where you're just being like, oh, right. And of course, and of course you have to remember that this is, I think 2005, I think that's when Firebug was originally released. And that was the thing that really changed web development where you essentially, before that point you had no console to speak of to investigate things. And you're just like, you get these cryptic errors from an explorer that are just like, you know, object, object, undefined, or whatever nonsense it was. And it just, you couldn't investigate anything. And for, for me, like I think other developers at the time, like Firebug and Firefox, like changed, completely changed the dynamics of developing. And then I was using, along with other people, you know, using, there was like libraries like Prototype at the time, which was a JavaScript library. It was mainly used in like applications, but very well-designed. I liked it. And, but then I saw an opportunity. I'm like, hey, we, you know, if we have stuff to better, you know, manipulate the DOM, better, you know, support, you know, kind of progressive enhancement on pages, you know, this is an opportunity to make a better API. So that's what jQuery really threw out. It was, yeah, again, inconsistencies and Ajax and all this sort of stuff. Yeah. Right, right, right. So you're like, and for developers, new developers now, there's no fetch. There's this concept that has this like tiny little object. But even, I think, I think John, even manipulating the DOM was a mess, right? Like those APIs weren't standard across. So you also, like just creating an element on, on a page was, was like, you could, you could spend half a day. Like, did I, did I get that element right? That one strange element on there correctly? Yeah. Yeah. And the performance problems were way worse as well. Like you had, we had to do all sorts of cheating of the APIs to try and squeak out better optimization because the browser was just really, well, the systems were a lot slower and also they just hadn't put in the work to optimize the APIs as much. Right. Whereas everything now, everything is optimized within, you know, fractions of a millisecond or whatever. Yeah. Yeah, yeah, yeah. And I think, cause like the original web wasn't even designed to be doing what we're doing where we're like, like that Ajax thing, right? We're pulling it down a document, but it's like a chunk of something at most, most times. I mean, and so that's, I think that's super, that's a super interesting swing on it. And then, so you came up with this library, you come up with this library and people are like, oh my gosh, thank God. I can, now I can write some code. Can trust that someone has thought about all of these, that, that was 60 lines of if statements, but like literally step by step and letting us, letting us build these bigger applications that, I mean, I mean, really like you take, you would, you think about an application that you see today used to think when it was like single page apps where all sorts of interactional, that would be almost impossible to think about doing back in the day, but people started moving forward. And I feel like that really like, thank you, John, for that, for that, for making that adapter on top of it and making people understand that like, hey, these browsers are different, but guess what? We can handle it with this library. And I know that you had tons of open source contributions from that, which is also very cool for the, for the web community there. We brought open source, the docs were incredible. I feel like y 'all like over time got so good with the docs of like explaining, oh, here's how that goes. A lot of the things from jQuery itself ended up in the library, in the library itself. Cause like, even to the point of like, I think is array, like, right. Is this thing an array or is this an object with some weird number? Cause all the array implementation was weird too. And you standardized that. Yeah. Yeah. So I think it's interesting. It's just like, it's, I mean, I feel very thankful for the fact that, you know, the work that we did, you know, we were able to work with, you know, standards bodies and with browsers and to try and advocate to get them into the browser because ultimately jQuery shouldn't exist. Like, you know, like, I mean, there can be, you know, there can be things that it can help with, but I think at the end of the day, having the browsers provide these better APIs is, is the ultimate way. Cause then everyone has access to it. It's a better, you, whatever performance you can get out of, you know, native browser APIs is going to be way better than what you can do in JavaScript land. So like, that's the sort of stuff where it's just like, Hey, let's, let's do that. And so, yeah, I think, you know, nowadays, you know, obviously we're in a whole different world now where we have bigger frameworks and meta-frameworks sitting on top of things. So like jQuery is not really even factoring into most developer conversations these days, but, but like, I think this is yeah. I'm just glad that it was able to help the web in some way here. Yeah, for sure. Absolutely. And pave the way, I think, pave the way for like, here's how we can make standards and here's how we can, I mean, even the adapter pattern itself, I feel like just the thought of like, Hey, this isn't quite ready. I don't, I don't, I never heard the word polyfill until way later, but I was like, Oh, that's what jQuery is doing. jQuery is doing a polyfill. I had never heard of that word before. But like, so, so really thank you. We all, we all thank you. And I would also like to say that like, I was doing some research on it today because I was like, well, how, how wide is it? There's still 70%, it said 70% of the Internet still runs jQuery, which is interesting. Like, like, like you were saying, because there are other, there are other frameworks. How does that feel? How does that feel to know that like 70% of the Internet? It's wild. Like I, so, I mean, I stepped down from the jQuery project in 2011 and I did it for five or six years there. And I was just like, I'm done. I gotta, for my own mental health, I need to take a step back. And also I wanted to be able to work on applications. And I went and moved to work at Khan Academy, education nonprofit. I've been there for almost 15 years now and it's been awesome. And, but it's, so like, I think for me, it's like, it's a different part of my life where it's like, I can't believe the work that happened back then. It's still having this ongoing life and impacting people so much. And yeah, I don't know. It's, it's incredible. Do you, do you, do you have advice for people who are still using it? I mean, I mean, now you're not, you're not there at the, at the, at the helm of this anymore. And I know that they're still pushing releases out. Right. Because I guess, you know, things are still changing. There's still new, new things to sit on top of. Do you, do you, would you advise somebody to, to look at, into it? I, I guess there's this like, there's this war, there's this like war of library framework, library for, and I know that you were in the throes of that back in the day. That's not a framework. It's a library. Yeah. I mean, it's interesting. I think that it really depends on what you're trying to build, but I think that by and large, you're probably not going to want to build off of jQuery for a do thing that you're building. I mean, I think there's a couple of factors that go into modern web development now, which is, all right, where's the community? Where's the documentation? If you're having problems, how do you get support? I don't think that's in jQuery land. You know, like for, you know, there might be good docs, but like, are people building new things there? Not really. Like, you're probably going to have better luck if you're using something like React or something like that. There's a ton of people using it. Yeah. And so I think that's the sort of thing that I always look for when adopting any new tool. And I think that absolutely holds here. Now, I think there's another factor, which I think is interesting, which is that, you know, using tools like Cursor and like having LLMs doing code generation, I'm willing to bet that, you know, LLMs are trained on a ton of jQuery code, you know, just because it exists. It's got to be everywhere. So I haven't, I realized I should probably experiment with this now. Like how well can it just write like a basic jQuery app with an LLM? I bet it can do it pretty well. Anyway, so like the, but I think that that is another factor there where it was like, if you're using tools like that, you've got to make sure that it's trained on it. And it's certainly like, I would say that, for example, again, like I've used tools like that and it works well for React and stuff like that. So yeah, anyway. Awesome. Awesome. I have a question that I think only the people who are like very, very nerdy here are going to go back this far. But when you introduce the dollar, right? So the dollar thing, what was the motivation with calling that the dollar? And then did that affect, I see that, like I see that in the Chrome dev tools, I can use dollar and then I can use the CSS selector. Is that from jQuery? So it originally was from Prototype. So Prototype has the dollar sign as a function. And I believe their version, you gave it an ID of an element. It was a quickie for get element by ID, essentially. And I really liked that. And I was like, oh, that's so short and cool. And so I'm like, I'll use the same thing. But in the very first version of jQuery, you could pass in an ID or a CSS selector and it would figure out which one to do. So it's like a parody Prototypes API that eventually it's like, okay, now actually the very first version, it was an ID, CSS selector or XPath, which is again, a whole other thing. But now it's a CSS selector. Yeah. Awesome. Awesome. So what are you building now? You're over at Khan Academy. And what's your framework of choice right now? What are you building in? Oh, gosh. So I think at Khan Academy, we're generally like a single page applications, plural, but at the moment, we use V for dev server. We actually use RSPack for production at the moment. And we're pretty big. We're a couple million lines of TypeScript code. But the thing is, our code base has gone through so many generations. When I started, we were jQuery backbone handlebars. Okay. Nice. And we were the first adopters of React outside of Facebook. And then we went from React pre-classes to React with classes to functional React and with hooks. And we've gone through every generation of React. And now we went from no types to using flow types to now TypeScript. And anyway, so our code base is, even if you think about all the generations of work we've had to go through here, it's actually pretty modern. Some of the things we're working on upgrading now is getting onto the latest versions of React router. So we're on five and six, and we're trying to get fully up to six, and then eventually seven. Now on my side projects, that's where I'm using the Cloudflare React router seven. Nice. Yeah. There's stuff like Biome for linting and stuff like that. Yeah. So my tool stack is pretty similar in both places with a little bit of squinting, I guess. Okay. What's your side project that you're working on right now? What's it that you want to talk about? Yeah. So I always have a couple, but one I've been working on for many years is a website that's a database for Japanese woodblock prints. So this is an art form mostly from the 19th century, and people were making prints in Japan and selling them. Anyway, it's an art form I like. So I built this website that just pulled prints from different museums and all over around the world, and just to have a place for people to see them. So I have that built on top of Cloudflare using workers, do all my image storage in R2, and I use D1 for all the database and storing all that. And so, yeah, I mean, that all works well. I mean, yeah, we can use it and I saw the announcement this morning with the new V plugin. I'll go in and I'll get that upgraded here. And so we'll talk about that. Awesome. Awesome. Well, hey, I've got that team here, John. I have that team here, so we can bring them on. We could just get some full hand, right hand support. But then I'm working on another project here, which is more of, again, it's Japanese print but scraping and collecting prints from dealers in real time. So it's going and looking to see what comes up for sale. And for that, I'm also using Cloudflare, but also using a lot of workflows, tons of workflows and doing a lot of coordination and then also a lot of AI stuff. So doing data extraction and just infrastructure outputs, but then also using AI to help bin stuff into categories and do all sorts of things. So that's something that I've been very, and I was seeing the announcements yesterday for Cloudflare Workers. I'm very excited to see. Right, yeah. Going GA. So, yeah, I'm fully bought in. Awesome. Awesome. Wait, let's do this. Let's bring the VEET folks in. All right. So, John, welcome. This is the team that put together that VEET plugin. I would love, I'm a backend guy most of the time, so I'm excited about whenever I hear that somebody's made it easier for me to get something going. And I would love to know, let's just for people at home, let's just do what is VEET. Peter, do you want to take that? I think we should actually hand that over to Patek because Patek, along with a couple of other people, I think you could probably do the best job of explaining where VEET is and what it's doing. Hey, everybody. Yeah, I'm representing the VEET team. The VEET team is quite big right now. But yeah, so VEET is a build tool like you have used previously, like Webpack and things like that. Now we are, I saw today like 25 million, so like quite close to reaching that Webpack level. And the idea is that during build, you can sync it off, kind of like I open United's road app config. My road app is a kind of bundle to build your, like if you use, for example, Vue or React, JSX, you need to convert that to something that the browser will understand. So you need to bundle your code and like transform it. And during dev, the idea was that VEET will not bundle anything. This was like the innovation and just start a dev server, but it's a smart dev server that when the browser will request modules, it will, if it is TypeScript, for example, it will distribute the types, give it to the browser so the browser can keep going, import other things. And if you give it JSX, it will convert it to JavaScript so the browser can keep going. So you can sync it in during dev as this kind of very smart static server. Awesome. And VEET means fast, I believe, right? If I'm correct, is that what it means? Like, what's the root of the word VEET? Yeah, it means fast in French. Like this, the browser was started by Evan Yeo and like Vue is also like Vue in French. So like he has a tendency to use French words for the projects. Okay, nice, nice. So it's a really fast startup and it really is fast at like pushing the things across as it needs to go. Again, I think at the same sort of level, right, of like making this stuff, this stuff's all over the place of how you package things up. And this is just kind of bringing it all together without you thinking too much about it to get out of your way, right? Kind of, again, helping to build a better Internet, right? Like we're able to build these better web pages now because of this VEET team, I believe. I believe. I'm not sure if that's everybody's vibe here. I think one of the things that really struck us about VEET is it's kind of similar to where jQuery is coming from. Like it's pretty agnostic. Like it just sits there and does its thing really well and people can build stuff on top of it. So there's now so many frameworks that have just decided to ditch whatever tooling they were using before and just sit on top of VEET because it just provides that infrastructure. And then you can just focus on doing what you do well. So I think that that's been a massive game changer and you can just see it kind of rolling out, obviously not quite as extensively as jQuery did, but like it's definitely getting there. The number of stars, the VConf that happened last year, that was earlier this year, was just really exciting and it's kind of progressing really nicely. And I think this is what we saw in Cloudflare. We could see developers are using VEET and we had Wrangler, which is like a really cool tool, but you were kind of stuck in this kind of situation where VEET provides this amazing DX where, as Patak, you were saying, when you make the request then it goes and gets the code and strips the types and sets everything up and pushes it to the browser or wherever. So things happen really fast. It doesn't matter how big your app is, you just only get the code that you need at the time. But if you were using Wrangler, then basically the approach is that you build the entire thing first and load it into the Cloudflare engine and then run it. And that means that the development cycle is much slower because you make a change, you've got to rebuild the whole thing and that slows things down. And so up until recently, we've always had this kind of tension at Cloudflare if you're a web developer, it's like, do I go with something VEET where I get this amazing DX, but you're not actually running the code in the Cloudflare Workers' runtime and you also don't get access to the bindings and that kind of thing? Or do you go with Wrangler, which means that you get a really high fidelity scenario where everything's just how it's going to work in production, pretty close, but you have to wait for the build each time. So we were kind of stuck in this situation. And then James and Patak and some of the other VEET team were having lots of conversations last year. And the VEET team, maybe you want to speak about this a little bit, Patak, about you introduced this new concept called a VEET environment, which allows other runtimes to actually run inside VEET, which then we built on, which we can then talk about with our plugin. Yeah. So at first I want to say thanks to all of you in Cloudflare because I just posted that I don't think this environment API will happen without all the feedback that you have given and the push saying directly, this is not enough, we need more. So thanks first. But this started, the story is very long, but making it short, the engine of VTest that is the equivalent to Jest in VLAND that let you run testing code, it's called VEETnode. And this was a way to run, using VEET, run in threads, in workers, in other places. And we decided two years ago that we will move this inside VEET core because we saw the opportunity that, like you say, you could transform things using the VEET server, but run it in other places. For example, in Miniflare, like running the worker did. And Vladimir Sheremet, a big shout out to him, he ported that and this happened during one year, we got it, it was called Runtime API, we put it as experimental, people started to try it out, Cloudflare started to try it out, and we got a very long discussion in the VEET repo from Igor Minar, and I think we discussed it with the rest of the team, saying, this is not enough, we need more, this is what we want to achieve. And we were just at the Vue.js Amsterdam, Vue.js World Conference last year with Vladimir, sitting down reading that. And we decided at that point, we started to, with paper and pen, and started to draw what become an environment API. And it was another effort of another year that we ended up releasing, I think it was November last year or something around that. And as I said, during all that process, there was a ton of involvement and constant feedback with all the iterations that we did to see what is the best API. So thanks again. Awesome. Well, I mean, that's also everybody who's using VEET, that's such a nice thing to hear, right? When people are taking feedback and making it go forward, I think that's the beauty of open source there, of that going, right? So also thank you for listening there to the feedback. And so we went and we worked on that plugin, and now what can we... That plugin is live now today, which John Reza was talking about, he's going to upgrade it to use this plugin. What does that plugin do? Let's take that one. Yeah, I'll pop in there. So I think we kind of started to think about the different way people use VEET. So VEET initially was very much about building front-end applications, SPAs, and it became a sort of de facto way to develop React and Vue apps and those kinds of things. So we started thinking about how we could support that as best as we could, but do it in our own way so that it's very easy to add a Cloudflare worker as a backend API so that people can basically have their front-end application. They can have a backend API and they can deploy them all as a single unit and everything just works in development as in everything's very integrated, which is really nice. So that's kind of the foundation was getting that to work. And then we've been in discussion with various full-stack frameworks about how we can integrate with their integrations with VEET. So the other thing we announced today was the first one of those, which is React Router v7. Hey, there we are. Nice. So this basically, the two plugins sit alongside each other. So you'll have the React Router VEET plugin, you'll have the Cloudflare VEET plugin. And I'm really pleased with how it works because they're not coupled really in any way, but they just work in harmony because of the way this environment API is designed. So our Cloudflare environment essentially takes over the server side rendering portion of your React Router app. And then that means all that is happening inside the worker's runtime. And then when you come to build and deploy it automatically, it's going to put it up onto Cloudflare. So yeah, that's the first one of these. And we're hoping it's going to be the first of several really. We're talking about the full stack. Awesome. I don't think people realize in general, like how good we have it now compared to where build systems were, you know, five, eight, 10 years ago, where really in order to be able to generate a functional build that would be capable of being server side rendered and client side rendered and everything is talking to the right bundles and et cetera, et cetera, like it was a project to do. And especially, you know, in that case would be, you know, probably Webpack or whatever. And now it's just like, oh yeah, you just toss your two plugins into VEET and it just works, which is, I think is personally just phenomenal dev ergonomics. I mean, I love it. Yeah, totally. And I think, you know, there's a lot of possibilities in the future with this as well about like, because there's not a limit on the number of environments you can set up and all that kind of stuff. So we can, we could have multiple, multiple worker bundles that are getting pushed up and deployed as part of the same application, but connected to each other and all those kinds of things. So they're the kind of things we want to start exploring with this as well. All those, all those new things that are starting to become possible now. Awesome. One of the things that we should like just play note to is like one of the driving forces behind this is that in Cloudflare, we have all these bindings, right? So you can connect to all these, the resources and databases and buckets and so on. And that was really hard to do when your code was running in node, right? Because the bindings are in worker D in Cloudflare workers, but your code's running a node. And like, how do those two things come together? So Daria was actually heavily involved in like a kind of halfway house that we built, which was called get platform proxy, which basically creates a property that runs in node that then connects to the worker's runtime in order to connect to the bindings. And that allowed you to continue to build your app using Vite, running it in node locally, but then still accessing all these bindings. So your, your, your actual user codes works well, even in local development. But this, this was always a bit of a, like a plaster over a patch, a patch over like a little scrape. And we wanted to do better. And the, and the environments was exactly what we needed. And now you can literally have all of your bindings in your code running purely in, in like Cloudflare Workers. And all of your, the backend part of your app will be running as though it was actually in production. And then seamlessly working with the, the full stack framework, like router and other ones that are going to come along. So fingers crossed. Yeah. Right. Well, it just kind of all fits out in the, and the developer doesn't have to think about this. Like the application developer just focuses on their business logic. What does the app got to do? And then all of the plumbing Vite does an amazing job of like dealing with all of the module side of things, the runtimes dealing with all of the binding side of things. And you can just focus on what you want to do. So it's a, it is, as John was saying, like it's, it's a really nice place to be right now in terms of focusing on getting the stuff that makes the difference from your point of view. Nice. Yeah. One thing there that I think is very important also is the, the way that you are interacting with all these full stack frameworks is extremely important because it's similar to what we do in Vite that we are always talking with the ecosystem. Vite is where it is like in part because the ecosystem decided at one point, we, we need to share like peace and let's all work together on this. And the way that you have like done open source with this, like with the plugin being open source as a reference to others that want to implement something similar and actually not only doing the plugin and putting it out there, but like doing the plugin while working with different like framework maintainers, like checking what are their needs, how it's going to work there, like changing it to fit like what is already happening to try to even like thinking about like what are the stages to drive them towards where we think like they could get the best out of Clover. This is, this is I think extremely important. And it's a lot of work that I don't know if it is seen after just someone like John said, like just put the plugin line there and it's working. Okay. I will continue on something else. Yeah. Yeah. Yeah. I think that, that appreciation. So I think that's, I think that's pretty much a common theme of, of this, of like making things easier to build and faster because you've got stuff to do. You don't need to be thinking about this stuff, right? You don't need to be thinking about, back to John, you don't need to be thinking about these browser inconsistencies and on this build thing, you don't need to be thinking about the build system inconsistencies and what can I do in this build system versus what can I do? Hey, you can just do it, right? You just, you just do it. And it's all because of, of the work of, of, of this team and the, and the broader team. So we really appreciate that. Thank you for, for coming and talking about that and bringing the bindings, right? I love the local development of a front-end web app feeling like it's going to feel when you go to deploy it and you don't have that loop of like, you lose time in that loop. You do that loop and you're like, oh wait, what was I doing? Oh, I'm going to go let the dog out. You know, like you forget about what, what was going on. So like that XKCD comic about the building, it's building time now. It's just, it's, it's VEET. It's, it's fast. So thank you. Thank you everybody. Thank you for being here and sharing that. Everybody go read the blog post about this and go use the VEET plugin. There's lots of stuff to build. This is the full stack show. So I'm going to let you guys go here and, and as soon as like my mouse comes back and we're going to bring out I'm going to bring out Thomas to talk about I'm going to bring out Thomas to bring out to talk about the backend. One second. I'm almost there. My mouse, I lost my mouse. It's back. Thank you everybody for, for being here. Thank you. Hey everybody. This is Thomas who is going to talk about some very exciting stuff that happened today with regards to hyperdrive. But before we get there, Thomas, what's hyperdrive? Hey Greg, nice to be on. So hyperdrive is our feature of workers that makes it possible for you to have really fast connectivity to a traditional SQL database. So we know that a lot of people are trying to build full stack apps on workers. You're trying to connect to your Postgres database or your MySQL database. Now that's, that's what we just announced today. And we want to make it easy and fast for you to be able to go and get that data from workers all over the world, right? Your database is probably going to be in a region, in a specific region, and we need to make that fast. And hyperdrive is our product that focuses just on that. Nice. And I think continuing with the theme about making things easy, hyperdrive comes with some features, right? Like hyperdrive does some of the heavy lifting. John, are you a user of hyperdrive? I'm not yet. I'm using D1, so I don't, I haven't had the E4, but I mean, I have questions for later though. We can get to that. Okay. You feel free. John, you feel free whenever, whenever the questions come. So I guess, I guess it's just a general question because I mean, this is phenomenal for, for SQL stuff from what I've seen, but I'm also curious about non-SQL databases. And so like, just as an example, like one project I use, thanks for us, MealySearch, and, and which is a Rust-based full-text search engine. And unfortunately, you know, there's, there's certain tools that do things that traditional SQL databases can't do. And I, but the things I would love the benefit of stuff like this, of like being able to, you know, have that low latency and, and, you know, fast connections and everything. Anyway, I guess it's when I, when I see the hyperdrive stuff, I'm just like, oh, I want this for everything essentially. There's so much, there's so much to unpack in what you just said, John. I mean, yes. So first you mentioned you're using D1, like clearly D1 is built for the edge, right? And it's, and it's built on this ability for you to be able to connect to it without having to set up this whole TCP, this whole TLS handshake, this whole database connectivity handshake. And like, that's really what, what hyperdrive is solving, especially if you're, if you're using it without cache or anything. So like in, in that sense, like, like you said, D1 doesn't need it, but a lot of other databases are still in that traditional sense. And, and here's, here's the challenge. So the way that hyperdrive works is it actually parses the wire protocol. So it parses both the Postgres wire protocol, and we added support now for the MySQL wire protocol. And it needs to do that in order to know whether a query can or cannot be cached on Cloudflare's network. And so for us to add a new database, like there, there's some, some work involved in all of that. And so of course, like we're starting to get, we, we have a pretty extensive list of other databases that we want to support. MySQL clearly was on the top of that list. And, and slowly and gradually, we think we're going to get through a lot of that. Melee search, I'm not sure if it's the next one, but I think that like, clearly like hyperdrive is our solution for that. And there's a future where you get all of this out of the box. Interesting. What is it? What does it look like? Oh, go ahead, John. I'm just curious. No, go ahead, go ahead. Admit, how do you determine the caching characteristics of the query? I mean, I guess I assume, do you start invalidating the cache whenever you start doing mutations of any sort? Do you assume that there are no other connections happening to the database from elsewhere? So, so right now the, the caching for hyperdrive is actually pretty simple. You can have caching enabled or disabled on your hyperdrive. And we want to make that, like, we have plans in the upcoming couple of months to make it possible for you to have that on a more granular basis, so on a per query basis. But essentially today, if you're making a query, a read query or yeah, select star or select anything, we're actually going to be able to know whether that query can be cached. In that case, we're going to be caching. And, and honestly, that is extremely powerful for a lot of folks that are building on workers, because, you know, we, it's almost about 50, 50, the amount of people that are using hyperdrive with cache and hyperdrive without cache, because when you have cache enabled, you can actually have really fast access to either configuration or routing data or other stuff that you, you can be eventually consistent, right? Can update after a certain amount of time. And on the flip side, we have a lot of folks that are building admin type applications where you need direct access to the database, you need everything to be consistent. And that's when you'll also have smart placement playing a factor to make sure that that's close to your database. But we actually see like a pretty half and half split because you can get either or, and actually, some folks are doing both within a single application. And those are the ones that we are planning to build granular caching for. Today, the experience isn't perfect, it's doable, you can create two different clients, two different hyperdrive connected to the same origin database. But we definitely want to make it possible for you to have a single hyperdrive configuration and be able to, on a per query basis, determine whether this can be cached or needs to go to the origin database. Awesome. And then Thomas, this is also kind of at the adapter level, right? Like you're thinking about it, like, everybody needs to do these certain things. I mean, you actually set a list of it when you first started talking there about what happens when you connect to a database that's not ready to be on the edge. Like, can you talk a little bit about what that is kind of a little bit more down that path? Because I think everybody that hears about this is like, wow. Yes. And I actually want to take you to our other blog and spoiler alert, we're also making hyperdrive free. And so this is our announcement that we have today is not only do we have MySQL support, but we're making it free. I was giving a little bit of suspense there, but we're also it's only been available to workers paid, but everybody's been using it to build with SQL databases. We've been using it internally, right? The KV team at workers KV, D1 workers built, they're all using it to connect to our Postgres cluster. And we realized it's such a critical service. Let's go and make it available to everyone. So that's what we did. And so in this blog post, we actually go into the details of everything that's required. When I mentioned earlier, the multiple connection setup, this is really the hard part, right? And a connection, since workers are stateless, it can't be persisted from one worker invocation to the other. So that's adding a lot of latency. And what we do with hyperdrive- Every request. Exactly. Every request to your worker. And so what we do with hyperdrive is, let me zoom in on this one. Let's see. What we do with hyperdrive is we let you do the connection setup fully on the edge, fully next to your worker where that's happening. And then we're using an existing worm connection, relaying that in a single request across our network to go ahead and connect to your database, right? And so instead of having multiple round trips from a region that's far away from your origin database and your origin database, you have a single request. So it's as fast as it can be. This also makes it more easy for it to integrate with smart placement. So this is actually what leads to massive performance differences. We have a screenshot of our demo here. Oops, I'm going to refresh this page, but I actually wanted to take you to the demo. We have a demo. Go to hyperdrive -demo.pages.dev. I'm sure we'll get a link in here somewhere. But you can see the difference between connecting directly to the origin database from a worker and then connecting with hyperdrive. That's multiples difference. And it really adds up as your user is going through multiple pages, multiple different requests, and even more so when you have cached queries, right? We're talking single-digit milliseconds for those, right? So hyperdrive is really that tool and it's such a critical tool for that. That's awesome. That's awesome. And it's free. So it's free and we get MySQL. That's wow. Awesome, man. But it's also super easy. Maybe I should have led with this. It's also super easy to use. All that you do is you add your connection string to hyperdrive and then hyperdrive is going to give you its own set of credentials. Okay. So you can access it just like you would any other binding. But in this case, the hyperdrive binding gives you access to a connection string. And that's important because you can use your existing drivers, right? You can use PostgresJS, you can use Node Postgres, and now you can use MySQL and MySQL2 in order to make that connectivity. So it's basically a drop-in performance increase if ever you're doing those direct connections. Nice. So again, like an adapter, you're replacing that line of code. That's super cool. Super cool. That's awesome, man. Congrats on the launch. That's awesome. Congrats to the team. Team is super excited. I mean, everybody's super excited in our Discord. The community, the Discord, of course. It's been a long time coming and it's been an amazing Q1 for hyperdrive past couple of months. That's just been lots of shipping. Yeah, man. Lots and lots of shipping. Well, congratulations. And I'm loving that we've got our full stack. We've got our front end. We talked about our back end here, Thomas. And I'm going to bring on some people to talk about full stack. Thank you so much for being here with us today, Thomas. Thanks, Craig. Hello. So we've just talked about the front end. We've talked about the back end. Let's talk about putting it all together. What happened? What does it mean to do full stack on Cloudflare? I can cover that one. I think you can think of a worker as just like a server. And I think that's the most important takeaway for anybody is you can now, with worker support for static assets, you simply can use Vite, configure a directory where Cloudflare can find where your static assets will be. So your dist folder is typically what it is. And then when you run deploy, Cloudflare goes ahead and uploads and starts hosting that client side code for you straight away. So that's how you can start with a static site is it'll just be your static asset. If you want to make an API, you can go ahead and add a worker for your back end to handle that. That's basically what it means is you can have one project. Your assets are just configured in your Wrangler configuration. And your whole back end can be configured in a worker. I think this is so, so, so, so exciting being the OG Pages PM and kind of seeing engineers kind of run up or developers kind of run up against all of their different Pages issues with like, how do I build a full stack application on Pages? And Pages is just static sites. And we had all of these solutions and offerings for workers, which were so great and continue to be great. And we felt like we were just building the same thing for Pages. And I just love the story now. You can now do everything on workers, right? Everything that you want to build, the observability, the front end, the back end, the frameworks that you want all supported on workers. And I think, yeah, that's a really great story. We're really excited to tell. Yeah. I mean, I just look at the announcement this morning, like the feature I was excited to see it come from Pages land was the support for header configuration and redirect configuration inside the files. Because I mean, I've been configuring that separately, but being able to just have that in my repo checked in, that'd be, I can't wait. Yeah, that was actually a last minute addition. We originally had designed the project to be like, the worker is super powerful. You can configure everything in a worker, all your headers, your redirects, everything should just be built in custom. But one of the greatest things about Pages was that you could add those in static configuration and they were free. Every time you added those simplistic headers and your redirects, those were executing a static config, not as worker code. So we added that in as a part of this last release, even though we really believe in like the full routing capabilities of workers themselves. I was really excited to get that in as well, because I do think it's such a beautiful part of Pages that I'm glad we've carried over. Nice. How should we start thinking about Pages? I saw something. What should we think about for Pages these days? Yeah, I think Pages is, I think you can think of it as fully supported. If you have a project built on Pages, you don't need to do anything. We do have migration guides. We fully though recommend that if you're starting a new project, build it on workers. And I would recommend that you should port over your projects if they exist on Pages to workers, just because you'll get to, you get all the observability benefit. You also, if you want to expand your project to use something like Durable Objects, you can now. And new bindings are really only going to be available. Durable Objects are free now. Yeah, so that's good. Yeah, exactly. I think it's just going to be a much more supported platform, but we're really just seeing Pages as it's still supported. It's well loved. It was the gift to the Internet, but nothing's changing for that. And if something does change, you'll have like a huge amount of notice, migration tools, but that's just not in the cards right now. Great, great. And I know that we're so good at doing that. I'm glad that you brought that up. A lot of our documentation, a lot of our examples, a lot of the ways even you're building with LLMs, I think will kind of trend towards the workers generation or workers building of applications. And so a lot of the examples and the new kind of features that we add will be primarily on workers. So if you want the kind of latest and the greatest, I feel like workers is kind of the way. But to Karin's point, if you have an existing application on Pages, do not be alarmed. Awesome. John, you said earlier that you were using workers. I don't think you said you were using Pages. You were using workers for a single page application, but now this will be a little different, right? What are you getting here that you didn't have before in the app that you were? No, I'm using workers, worker assets, and I do the server side and client side with the whole, I'm using React Writer 7. So yeah, I think I'm using everything we talked about today. Now I can use the better APIs, which is awesome. Yeah, no, I mean, this is exactly what I'm hoping for. I think it's interesting. So I think a tricky thing with any sort of API transitions like this, where obviously the majority of the effort now is going to the worker-centric API, which is, I think it's phenomenal. But on the Internet, I find Cloudflare's documentation to be good, but then on the Internet, there's still people talking about Pages-related stuff for their tools. And it's sort of like there is this, if you think about it as sort of like a soil strata of people talking about Pages stuff, now people talking about workers-related stuff. And I think it's a challenge because React Writer, if you go to their documentation, it's all about workers, which is great. But then you go to some other frameworks, they'll be like, oh, this is how you set it up with Pages. And I'm like, oh, okay. But I mean, we got to get you, not modernized, but you can get all the benefits of workers if you make the shift over. So yeah, I'm very excited about the announcements today. And I'm just hoping that there's even more embracing of it to get more people onto these platforms. Yeah. I think that's kind of the next- They only had a day. The next few weeks will just be focused on updating public documentation guides at reference pages and making PRs against other partners that we have to make sure they know how to do on workers. That's kind of the next phase is actually making people aware that you can do full stack on workers and that the things that are core to Pages, you can also do on workers. Something that was really interesting when I first joined this team was even understanding how people thought about Pages versus workers was very different than even what was true. People just thought Pages were static sites. If you have anything to do on the server, do it on workers. But we had Pages functions and we now have static assets on workers. So I just want everyone to really think about workers as this overall platform where you can get down to the nuts and bolts of how do I actually want to build my app? I could just do a vanilla React SBA with the VEET plugin with Hono. I don't need a front-end framework. It's very nice and simple. Yeah. I think if you're going through and encouraging people to update docs or whatever, I'll just do a shout out for TanStack, TanStackStart, TanStackRouter. Because they mentioned- Yeah. Anyway, I think to me- Yes. Oh my gosh. They mentioned Pages, but let's get them onto workers. Anyway. Super good point. Yeah. And one of the things that we announced this week that we worked on was kind of allowing developers to instantly deploy an application through a deploy-to -cloud-flare button. Kind of a concept that's been around for some time, but I think there's some really unique things that kind of enable more developers to start building on workers, right? When they're- Originally, when you're building a workers application, there might be a lot of complexity to set up and kind of how do I get started? What's an example I can get started with? How do I install Wrangler, install dependencies, and all of these kind of really cumbersome activities that a developer has to do to get set up? With this deploy-to-cloud-flare button that we just launched, you can actually just click the button if the repository author has this button in the repository, and we'll set up a repository for you in your GitHub account. We will provision any resources needed in front of that worker. Let's say it binds to a D1 resource or a durable object, we will provision all of those for you, and then we will actually kick off a workers build and deploy that for you. So just in the spirit of how can we get more people building on workers, how can we kind of show people how acceptable workers is, this button is something I'm hoping to see not only in our documentation, not only in our blogs, but also documentation and kind of just content on the Internet for other providers and other companies as well. Yeah, absolutely love that. If it's their first time building an app here, it can be intimidating, and we don't want that. We don't want that at all. So I love that that is happening, and I think that you'll start seeing a lot more demos having all this button and templates to walk through, and it's going to be awesome. So I am also so glad that that landed today. Exactly. Awesome. Oh, I was just going to say, I know there's a lot of talk about, you know, like MTP servers, and I feel like that concept can sound very intimidating to developers. It's actually become our most highly deployed repo example, and I've seen so many tweets kind of on Twitter right now that are just like, I just got my MTP server set up in less than two minutes. And that's kind of the thing that we're trying to vouch here for. So not just, you know, how can you build a full stack up on workers, but like, how can you build kind of anything on workers, right? Our latest tech, our latest announcements, right? Making it super accessible and less intimidating for the operator to get started. Yeah. Awesome. John, are you going to put a deploy to Cloudflare Workers on your Japanese woodblock app? Probably not. I don't think there's enough demand for that, but they, yeah, no, I mean, that's going to be phenomenal. Awesome. Well, thank you both so much for being on here. And congratulations on the launch. What a huge, what a huge day for full stack on Cloudflare. What a wonderful day. And I'm looking forward to tomorrow as well. There's more stuff coming. It's awesome. Thank you both. Thanks so much. Thanks so much. Let's wrap it up. You got some building to do, it sounds like. You're excited to get moving here on the full stack Cloudflare. You know, I was, when I first started here, I was in that place of like, well, I need to show a demo on how do I make a full, and I was always confused about which way to go and how do I let somebody go and build this? I feel like as a developer educator, I'm so excited for what we saw today to be able to like build this out for you. And then you press a button and now it goes. It's like removing that, removing that hardness, the barriers to that and building quicker, which, you know, again, what a perfect co-host that you were because that's, you've removed barriers. I'm sure you're removing barriers still at your work, but like what I know of your work, you are a barrier remover, removal person. Yes. That is definitely a passion of mine. I'll put it that way. Yeah. Yeah. Awesome. Well, thank you so much for, for hanging out here and thanks for being a partner in Cloudflare and built in on Cloudflare. We love, we love to hear it, love to see, and keep us posted on what you're doing there too. And if you end up, if we get you, you know what, I'm going to tell, I'm going to talk with Thomas. I'm going to say, Thomas, we need to get that database. What was the database that you said you wanted? It's called MealySearch. It's a, yeah, it's a, it's a Ross-based full-text search engine. And it was really fast. It's open source and everything, but like, it's the sort of thing that is hard to do with a traditional SQL database, but yeah, anyway. Gotcha. Okay. Well you, you're, I actually saw a tweet where I think you're doing a, you're doing a little nice trick on, on, on D1 as well, aren't you? Your full-text search. What, what are you doing there? So there I am doing full-text search and, because you can, you can do full-text or a version of full-text search in a SQLite. There's some gotchas though, which is like, at least at the moment, Cloudflare's implementation really always handles like Latin character sets. So it doesn't really handle like Asian, you know, the other Chinese, Japanese. So there's that issue. Which is pretty important in what you're doing. Pretty important. So what I have now works. It could be better. But, but the, the other thing is that a lot of good full -text search engines have things like faceting so that you can say like, okay, here's the results. Now break that down. How many were by this artist versus that artist? And like, that's what you can do with SQL, but it's usually like either the most complicated series of joins known to man, or it's like a whole bunch of queries. Anyway, it just, it's so much cheaper to do an optimized database. Gotcha. Gotcha. Which is what the Mealy does. So I'm going to push for that because I know the Hyperdrive team has this list. I was going to be like, Hey, John Resig said he needs this one. So thank you. Thank you for, for, for coming here and I can push, I'll push whatever you need, John, whatever you need. You've done enough. You've done enough. Awesome. So thanks everybody for coming to developer week two with a special co-host, John Resig. So, so excited to have y'all here and I can't wait for tomorrow to show you what's going on tomorrow. John, thank you so much for being here. Really appreciate you taking the time and showing the interest as well. So thank you so much. All right, everybody. We'll see you soon.