Fullstack Cloudflare with React and Vite (Redwood SDK)

Welcome to Syntax. Today, we have a really interesting guest on to talk about Redwood SDK. So we had Tom Preston Warner on, I don't know, maybe a year, year and a half ago, talk about Redwood JS.

And, they've done a little pivot into something called Redwood SDK. And I'm I'm so excited about this that it's middle of the night for for Peter, and I just DM'd him. I was like, you wanna record right now? And he said, yes. Let's do it. So I'm pretty excited about it. Welcome, Peter. Thanks so much for coming on. It's a super pleasure to be here. I'm also really excited by by you picking up with SDK.

I obviously wanted to spread like wildfire, and I think it has some great ideas.

But, I want people to pick them up. You know? Let's chat about them. Figure out what's better.

Yeah. So I I just spent the last probably hour and a half going through it. So, like, I've got I've got a million Wes, and my headspace is in it. So the idea with with Redwood SDK is that it's a what what? A framework for building React apps on CloudFlare? Is that is that give us the pitch of what it is.

Yeah. Yeah. So, Redwood SDK is a React framework for Cloudflare.

It starts off as a Vite plug in, that then gives you server side rendering, React server components with client side hydration, and, then also real time capabilities that are provided by Cloudflare's durable object objects. Then Cloudflare is the platform, so what you get from them is a super fast edge network all over the world. You get a d one database.

You get r two so you can store your files. You get queues.

You get really, really great, abilities to serve images to the right devices at the right resolutions, and you basically get that for $0 a month or Yeah.

$5 a month. When we were coming up with the idea of what for what Redwood SDK was, I'm from South Africa, so I live in a in a rural community in South Africa. There are 2,000 people where I live. And for me, it was really important that I could build software that was good for people in my Sanity, and I mean good in terms of latency.

There are very few providers out there or hosting platforms out there that have have servers in South Africa, and, Cloudflare has them everywhere. I think they have something like 230 edge networks.

And, you know, Cloudflare JS a networking company, so they really, really know what they're doing when it comes to making things fast. So Yeah.

So I was I was very excited about this when I saw it because there's there's a couple things that I'm, like, bullish on right Node. And and one of them being the CloudFlare ESLint all of their products.

They've sort of been on on fire recently.

Releasing like, like, workers is really cool. The durable objects is really cool. Their queues is really neat.

And then, of course, like you said, it's it's relatively affordable, compared to lots of other options.

I went to to move my own personal website, which is a React based website to Wow. CloudFlare.

And I first moved it to Next. Js with server components, and I tried to use OpenNext. Js. And it worked pretty good, but we're we're not it wasn't totally there at the time. So then I moved it to to Wacko, which deployed great great twos to server components, and that is also based on Vite because I'm I'm pretty big on Vite as well. But there's not aside from Wacko, there's not a whole lot of, like, Vite and React Vercel components out there.

So the fact that this gives us that was was pretty exciting.

Totally. And, you know, the thing is we we first validated that Cloudflare was a was a good platform for us to target, and then we built the framework from scratch within Cloudflare's Worker d, runtime.

So we try to make sure that everything that we are giving you is CloudFront native, so to speak. Yep. But with the plugability of Vite. And Vite has just released or they're busy releasing the, React Vercel DOM Vite plug in, which is the thing that enables, React Server components. It used to be a Webpack only thing, and we kind of, like, shimmed a whole bunch of stuff to make it work. And now it was we we, like, deleted a 400 lines of code when we replaced it. So the ecosystem is catching up to React and React Vercel components, specifically in beats in Beatland.

And, I think we're the right product at the right time.

Yeah.

Another thing I noticed about it is that it's this is not like a framework built on top of these technologies, which maybe maybe Redwood JS Wes.

But this is more of, like like, an Wes, I I dare I say, an SDK that works with the tech that you want. Meaning that it's not like you're not burying all access to all of these packages that we know and love, like like Prisma or any other ORM stuff or any of the Cloudflare stuff.

You are simply you you import them directly like you like you normally would. Right? Was was that a intentional decision?

That was a incredibly conscious decision. I don't know if you've seen this image of, Elon Musk's SpaceX, where they have these iterations of the different kinds of rockets that they're building. Oh, yeah. Yeah.

So I was the cocreator of Redwood JS, and now I'm creating Redwood SDK. I don't think that there are many people that have the ability to actually or have had the opportunity to build a framework from scratch twice, and this is my second iteration. So I've learned a lot of lessons from building the first framework, trying to use it in my own startup, and then now approaching it for the second framework. One of the things that I really wanted to make sure that we did was that we didn't hide anything away from you. The moment we did that as a framework, it made support much harder for us because people wanted the optionality, but it also made it super hard to understand.

So for me, I wanted to get down to sort of the bare bones of what makes sense from a request from a request slash response model JS well as what made sense from from a type TypeScript position. I didn't wanna generate types. I wanted there to be no magic. And I've been thinking about this quite deeply, about why we ended up having frameworks that look the way they look right Node, and I'm talking about Redwood JS.

We had these things that were magic exports.

Essentially, you would we created, like, a DSL for interacting with our framework. You export a special thing named this special name, and it would do something special within our framework.

I think it's because people Yarn trying to emulate Rails.

Yes. Rails like, Ruby is a language that gives you the ability to define DSLs, like, off the bat. So there isn't much traceability in Rails. It's also just like everything somehow works. Some other imports, I don't know how exactly they put things together, but it's incredibly difficult for a newcomer to understand where the where everything is linked together in Rails. And you started seeing that in in many JavaScript frameworks.

So I wanted to take that away. One of the things I appreciate about JavaScript is the ability to follow where an import is coming from and where it's being used. So I didn't wanna hide that from you. I wanted to make sure you could trace it. And I think the result is it just feels so good.

Mhmm.

It feels so good to be able to just see where everything is. For example, anyone listening, when you want to declare a new route, you simply just go to your worker dot TSX file, and you can, like, register just like the old express days, you can register a regular route that is simply returning a response. So, I've talked a lot on the show about the, like, the standardization of the web and and very two of the big ones are the request and the response. Right? That's what fetch is built upon, and and so much of the so much of the modern web is is built on the request and response. So being able to simply just return a response object or being able to to return, like, JSX components, which may be be pages.

So having, like, explicit access to that seems really nice. I I think it's probably a bit more typing. Is would that be fair to say? A little bit more setup?

Yeah. Totally. I mean, we're not giving you sort of, like, return a redirect function, or we're saying, hey. Return new response with a redirect Yeah. Header.

But you can create those yourself. We just didn't feel that we that's the surface area that we need to provide things for you. You know, what's wonderful about request and response is that if you're interacting with third party services and you're returning a response, you can just stream the request directly back down to the browser.

We've also enabled that, via React Vercel components. So you can take like, say, for instance, you're chatting to AI. You could send off a request to an LLM. It can return a response, which is chunked by default. It's thinking. It's thinking. It's giving you Yeah. Bits of information over time. You can take that and just return it straight down the wire, into an RC component and update the React component.

And that feels so intuitive. It's just like, okay. There's nothing crazy going on here. It's the network. I'm dealing with the network and the browser APIs.

I'm just sort of facilitating it in between.

And a long, long time ago, I was a fan of saying this. Most, web development is actually just trying to share memory from one computer to another in a safe way.

Yeah. And if you can make those easier, if you can facilitate that in a simple way, it just makes everything easier. So I think we've done that by just standardizing and request response.

It feels like everything is possible. One of my favorite examples is actually uploading files to to r two, which is Cloudflare's on to s three.

You just stream it directly from you you take a file a form data, attach a file to it, push it up to the web server. The web server catches the request and streams it directly into r two. Like, it's like three lines of code. I don't know if you've ever had to deal with chunks in a multipart form data thing. Sucks. Yeah.

It's terrible.

It's really bad. Honestly, it's it's one of the reasons why I I I love Node so much or or or server JavaScript so much is that, like, Node used to have its own or it still has its own streaming, but then they implemented regular streaming. And just being able to use the same streams and request response on the client and on the server is is such a a beautiful way to live. I'm a big fan of that.

Having been a web developer for the past twenty years, I feel like this is the golden age. We are hitting a beautiful space and time in software development.

And, actually, you know, Redwood SDK is a response to generative AI by programming LLMs because an LLM or or or an AI agent will assist you in the decisions you need to make, whilst you're building software, but it will often lead you down a a rabbit hole. It'll be like, alright. You need a database. Here's NEON or here's PlanetScale or here's this other thing. And Yeah. Perhaps you don't know enough in order to make those decisions. So with Cloudflare, you just get that all you just get everything. Just use the Cloudflare solution. You don't have to create, like, a you don't have to install that service locally. You don't have to figure out how the API works. You don't have to create an account. You don't have to create a give them your credit card. You don't have to figure out how to ship it in production.

There are, like, these taxes that you pay when you use external services, and you don't need to do any of that. You just focus on the software you wanna write rather than the infrastructure that it runs on.

And people are probably saying right now, like, well, Cloudflare is a service, similar similar to Neon.

Why should somebody choose this where it only runs on on Cloudflare? Like, why can't you make this just like Node. Js or or server JavaScript agnostic?

So for us, the really interesting part about building software is putting it in front of people, getting your idea from start to finish as quickly as possible through the gate, and not having to worry about the infrastructure. To me, you're not building a product when you're dealing with that stuff.

And that's if you're someone that resonates with that idea, you wanna build stuff, you wanna ship your ideas as quickly as possible and not have to worry about the infrastructure that's hosted on, Redwood SDK is probably gonna resonate with you. I, however, see Cloudflare as rather as AWS than I see it as a Vercel, for instance.

It's a hosting provider.

Certainly, there is lock in there, and we have to own that. Cloudflare gives you a lot of things that a lot of other hosting providers can't, specifically durable objects and the tight integrations with all their with all their services.

It's world class. I I'm unashamedly in love with Cloudflare.

Yeah. Yeah. Honestly, people give me heck sometimes. They think I'm, like like, taking money from them or something like that. But, like, no. I'm I'm just an I'm enthusiastic user. You know? They don't they don't even I get free hosting accounts from everybody and except for Cloudflare. I pay my own way on Cloudflare.

So that that should say something. But, like, let let's talk about, like like, database as well. So if you're using d one, it's a a relational database kind of or built on top of SQLite.

Yeah. So if you're interacting with that, you're not using, like, the Cloudflare SDK. You're using, like, what, like Prisma or Drizzle or something like that. What's the database look like in Redwood SDK?

So we give you a standard starter. And for that standard starter, we give you Prisma. So we decided that that was probably the best DX that we could that that worked for us. But you're connecting through Prisma to d one, and you're just running standard migrations. Although, there are some problems with Prisma right now when it comes to migrations. So we've created scripts that work around that, and they are addressing it. And Prisma has some issues with their large binary. They have this Wes that's almost, like a meg in size, and they are reducing that. They're they're taking that out, and they're just making it pure typescript. So at the end of the day, things are just gonna get better from that perspective. But we also have a starter where you can just use Drizzle or any of the RMs that are your decision, or you can just directly connect to d one,

as you wish. But you don't have to use d one. Raw SQL queries. Yeah. You don't you don't even have to use that. Right? You could connect anything.

Yeah. And I mean and then in that case, if you're just connecting to Postgres or MySQL at an external service, then Cloudflare can also help you make that super fast. They have these I don't know what the I don't know what that product is called, but they have, like, a proxy or something that Yeah. It's called a hyper hyperdrive, I think. Let me check that. Cloudflare hyper hyperdrive. Yeah. And

what that does, it it because CloudFlare is, like, serverless I'm using air quotes here. They don't like when you use that word, but it will have a fat pipe to your actual where your database is. Because that's that's a big source of latency for a lot of people, where your database and your code are not in the same spot or if you have to do connection pooling and all that, those fun things that come along with.

That actually Node me think of something that we do. So we follow the request response model. So if you're if you wanna log in a user, you create cookies, and that that user data is stored in something we call a session. That session is backed up in Redwood SDK by, something called the durable object.

So a durable object I actually I don't think anyone really knows what a durable object is, but I'm gonna describe it as best as I understand it. A durable object is basically another compute instance that lives alongside your existing compute instance, but they're they are logically separated.

So in case of Cloud Fair, they have this thing called smart placement Wes you can place a durable object closer to the user and the worker closer to your database.

The result is that it reduces latency overall, and they will figure that out automatically.

Did that make sense?

Yeah. Yeah. Absolutely. They Okay. Figure out where to put it. Because, like, a durable object is backed by d one, and that database needs to to live somewhere. Right? And and they will try to do their best at figuring out where it will will actually live. We did a whole show on on durable objects as well where we, we distilled it down to, like, durable objects are essentially JavaScript classes that can maintain state, and they don't go away. Because that's that's always one of the the downsides to using serverless when versus, like, a long running thing is that you don't have memory. You don't have have places to keep stuff in between requests because they they spin down.

Such good tech.

Yes. I'm I'm a big fan of, of durable objects as well. And I Node there's several people working on, like like, a open source version of it, just kinda cloning the the API. So that's if anyone's worried about, like, lock in with that type of thing, I I don't think that would be too big of a issue. That's cool.

Middleware. Let's let's talk about that. So, like, Redwood SDK has has, like, proper middleware, meaning that you can you can step in and and stop things and set headers and all that stuff?

Totally. Yeah. So the entry point for your app is a function called define app.

And at the top of that file, you can define as many pieces of middleware as you want. And the middleware is just a piece a function that gets the request and the context, and you can modify the context or return a response in there.

And then it gets handed off to the root handlers.

And once it matches a root handler, and then we'll call a request handler. But we have this concept that we call interrupters.

Essentially, any route can take an array of request handlers.

So a good example is, that you can then use to interrupt the flow of the of the request. So a good example is, say, for instance, you wanted to do authentication.

Typically, you'd have a function that checks if a user is logged in or they have certain privileges, and then you'd allow them to proceed to the page. So with an interrupter, you can create this function, is authenticated.

You can check the session to see if they are logged in. And if they aren't, you just return a response that says, hey. You don't have permission to do this. You've now interrupted the request flow.

If you don't do that part, it will proceed to the next handler, and then it will show you the page. So you can kind of, like, take these functions. You can share them with your code base. You're like, this is how I check if people are logged in. It's a single function.

Yep. And what's really nice about that is you when you read the code, when you parse the code, you can see what's happening. You don't have to, like, dig into each request handler and say, okay. We're actually checking if they're authorized and they have the things. It's just this little nugget that you attach to the request handler and makes it really easy to read and share that functionality.

Those are two layers of middlewares. The one is, like, global, and the other one is more per route.

Oh, that's that's interesting because in Next. Js, they started with, like, a, like, a global middleware, and then they moved it to, like, a, like, a per route middleware.

And I I was never happy with with either of those. And then the the middleware also had a bunch of limitations as to what you could do with it. And whether you like middleware or not, I'm a I'm a huge fan of it. And my applications, I'm coming I grew up on Express. You know? I have lots of of middleware.

So it's nice to be able to to have the the full control over that.

So talking about full control, I like to say that we give you control over every byte that passes over the wire.

And what I mean by that is that when you render out some some JSX or you when you return a React page, it's usually mounted in, like, a document, an HTML document that has, like, a head, a title, a body, like a div, things like that, you know, the structure of your page. Redwood SDK gives you Sanity to define that as just another component, and you then give it to a method called render. So you say, hey. Render this document for these routes.

And you can do that for like, you can have a different document based on a route. Say for instance, you had a blog a section in your website that was just blogs.

You could remove the client side hydration from that document, and you would just serve HTML.

There would be no JavaScript going over the wire. And then if you had, like, an app side to your website, you then just include ESLint side hydration, and then you have interactivity, and then you're getting JavaScript and React and all the stuff with that. And Mhmm. Say, for instance, you wanted real time, like you had a dashboard that was that required something to update consistently or you wanted people to do multiplayer stuff, you switch out the client side hydration with our real time client side hydration.

So you really have the ability to ship, like, many multiple apps within the same worker.

And a typical use case for that is, like, when you have a marketing site, and the marketing site has, like, this button that's meant to tell you whether you're logged in or not. And then you click that button, and you always see it would be like, log in, and then it flips. And it's like, nope. You aren't logged in. Click this button. Yeah.

So we can just take that away. We just send HTML down the wire because we know if you're logged in or not. We handled it in the request. And then you click that button, and all of a Vercel, you get in all the JavaScript that you need. Oh.

And another use case for that is you can, like, break out of layouts.

Right? Totally. So, like, one one problem we have, both my personal website and the Syntax website, is we have, like, a an open graph image page where we wanna render out not the website, not the header, not the footer, you know, not the whole layout. And in order to, like, break out of the layout, we have to do this weird, like, folder based structure with, like, parentheses on it and whatnot Yeah. Which it's Wes can get around it, but it is it is kinda funky.

It doesn't feel nice.

No. So talking about Redding, though, one thing that I noticed that there's no client side router. Is that true?

There isn't, but you can add one. Since you control the you control the ability to initialize the client side stuff, you can add one. Yeah. And, actually, I have a early experiment where I took control of the browser's navigation events, and I would actually go fetch the pages from RSC. So I'd I'd have a RSC endpoint that I could hit. It returned the flight data, and I just replaced the conference using, like, the inject stuff in in in React.

So we might provide one that gives you that SPA feeling. Yeah. But it will be very bare bones, kinda take the same principles that we currently have that, you have full control over it. But it just facilitates what the browser,

offers you as an API. Okay. So Yeah. If I wanna build like, I'm thinking, like, if I wanna build, like, a full stack app, I'm gonna need, like, a 10 stack router or or React routers. I'm gonna have to bring that in myself.

How does that work in relation to the, I guess, the Define app? You have, like, the server router where you can you set all of your middlewares and whatnot. Node now is there two separate things?

No. It will be the the same app. So define app can take multiple, render methods.

Yeah. And those multiple render methods can describe different documents, and that the document just Node describe how navigation works.

So the initial response will include the fact that you are logged in and set the cookies and all that other stuff, and then Bos subsequent requests will still go through the middleware, probably hit, like, a API route. It'll just work. I should I should Okay. Create an example because I I it's kind of vague in my in my words because it's vague in my head.

But it is possible.

Node. And and you'd still be able to set up, like let's say I'm moving from my blog to my about page. What I would hope would be that, like, there's an React Vercel component payload for that page that's that's sent back. Am I you're able to do that?

Yeah. Yeah. Totally.

Yeah. Oh, okay. Entirely possible. It'll either just be, the payload and then, gets rendered hydrated as HTML. But if it Yep. If it has client side interactivity, then you'll get all that stuff, all the all the rest of the modules with it. No. I was gonna say, where are the downsides? I was gonna say there are none.

You Node, the the thing is we had two stars from scratch to do this. We couldn't take what we had and build it on top of there. And I think it's rare that people can do that.

So I feel privileged to be able to bring this to people and say, hey. I've learned some things. Here they are.

Try them out.

Yeah. Yeah. Totally. Plus, like, you've been able to sort of sit and watch, like, what what's been happening with React Vercel components over the last, what, like, three years or so Yeah.

And see how the

issues people have hid and the the pains they've had. Is is there anything around that that you've you've made? So, I mean, we implement pretty stock standard React Vercel components. Like, the default experience is the one that we are providing despite the fact that we have, like, this, this way to stream chunk responses from a server action. That's one thing that we brought to the table.

Like, our real time actually plays along quite nicely with, rack server components. So say, for instance, me and you go to a page, and there's a server action on this page, and we have we have the real time functionality instantiated.

If I perform a server action that updates the UI and me and you are on the same page or key, you will get that update automatically.

So that's a a not an explicit behavior, but it's one that you can opt into. So, like, React Vercel components, if they update state, the server is the state. All the clients that are connected to that server receive the updates for free.

Oh, man. It feels really nice. It kinda, like, the mentally, it makes sense. You're like, oh, yeah. Of course. Because that's how React actually works in the background. When you push up a server action, you get the full payload back, and then it diffs it. So we're just doing that exact same thing for everyone that's connected to the same channel.

We broadcast the whole thing. That's cool. That's

I I've been playing with, like, Sanity Kit quite a bit as well, which is, like, a real time thing built on top of durable objects.

But you're saying that this maybe even I don't doesn't take it further, but, like, this is the implementation where it's just standard React Vercel component data, but it's also live?

Yeah.

Exactly. Oh, man. That's so if I were to if I were to have, like, a, like, a server component where I I queried some data and I put that data in my a client component, I would assume, then it would be and then somebody else were to update that data, then it would just immediately be real time. Yeah. That's cool.

Yeah. Yeah. And that update is coming from the server, the source of truth?

Building applications and thinking, like, what if everything was real time? You know? Like, you you you could, like, literally

with enough terrible object and everything. Yeah.

And it will scale. I mean, they say it scales infinitely, so put it to the test.

Yeah. Yeah. We'll we'll have to see. I've I've built quite a few things with durable objects, and it's amazing how how simple and good it actually is. Like, I I had this little LED grid, and I built a little app where you could draw in the browser. And then it immediately was just mirroring it right to the LED grid. And, that's cool. Wow. Yeah. It's it's really nifty.

Was that, with an ESP 32 or something? Yeah. Yeah. ESP 32 hooked up to,

16 by 16 matrix, something like that. I need to finish it as well, but I was just looking for an example of to to use, Sanity kit in real time.

Super cool. Yeah.

Yeah. Like, Sunil is he works at Cloudflare Node, and he was actually the first person that I showed this to. We both had Scott ups around about the same time, and Mhmm. I kinda leaned on him a little bit for emotional support. And now I still do for for emotional support, but just to cheerlead what we're doing, and he's so great. Yeah. He was like, dude, I need real time React. And I was like, okay. I'm gonna make it happen.

So what happens to the old Redwood or, like, what red what we used to know as Redwood JS?

So we've renamed Redwood JS to Redwood GraphQL, and we're trying to give it the same treatment that we're doing to Redwood SDK, which is to say that we're unbundling all the major packages that were shipped with it so that the users who are still using Redwood GraphQL can just take Vite plug ins, take the ecosystem as it stands, and control their own destiny. Mhmm. But and will still maintain security patches and and bug fixes for the core of it so that the people who are still using it still have a good experience, but one that they can run and own themselves.

I'm cognizant of you know, that that was my that was my baby. That's the thing I'm super proud of. It's not every day that a a boy from South Africa gets to build a framework with Tom Preston Warner.

I still somehow can't believe that happened to me, but, I'm really proud of that work there, and I'm really proud to take on the legacy of of what we built and and, you know, try and make it spread in the world. We we just couldn't make Redwood GraphQL, happen Redwood Wes happen. It just didn't it didn't find a solid footing in the market, and,

I'm I'm here to change that. Why do you think that was? Because I am constantly shocked that nothing that is trying to be the Laravel or the Ruby on Rails of JavaScript has has caught on. And I I often Node, we're like, yeah. I wanna I want something that's opinionated as long as it's my opinions at the moment.

If I think about it in my own philosophy, I think the really hard part about building software is not actually writing Node. It's gluing together services.

And you would feel that, like, when you were trying to integrate Storybook or, you know, like, one package and another, but it got really hard when you try to ship to production.

That's when things started to suck, and your hosting provider just could not help you.

Then you had to go and search for another queue library. And, you know, that fatigue of trying to figure out what works best for the thing you're trying to build makes building software worse. And I think, you know, Redwood was built upon that concept. It's like, we'll integrate with this. We'll integrate with that. We'll give you this auth provider. We had I think we have, like, 18 auth providers.

So we didn't actually take your decision fatigue away. We just kinda made it possible.

And, I think we could have been more opinionated. I think I think a framework requires a platform. I know that might be a little controversial, but I think it just makes software development easier and better if the platform is right alongside the framework.

You mean, like, a platform, like like, a infrastructure platform?

Yeah. Yeah. I mean, like Yeah. A CloudFlare or a Superbase or something along those lines.

Totally. And, quite honestly, that's that's why Next. Js is is so popular. Right? Like, Vercel made it extremely easy to deploy and to write the software, and it just it just works. And I don't think that Next. Js would be as popular if you had to go and and host it yourself somewhere. You know? It's just not Definitely. It's and and it happened with with WordPress as Wes. JS the reason why people love WordPress is that like, somebody DM me the other night. They're like, I don't wanna use WordPress, but there's literally nothing else that is that cheap and easy to deploy somewhere else. And it's it's not a problem of the software. It's it's a literally infrastructure thing Wes these Yeah. These GoDaddy's and Bluehosts have have made it so easy to deploy these things, and and the software has really benefited from it.

Totally. And, you know, I think we were a little bit too early with, Redwood. Js.

We kind of saw, Netlify. They released these Lambdas that were based on AWS's infrastructure, and we were excited about that. And we had this idea that those things would just continue improving over time.

And Yeah. They didn't. They just didn't. And they had some really, really big restrictions that we didn't fully appreciate at the time warp didn't accept that they would stay that way.

And Cloudflare, I think, has become the answer to those things. I mean, like you said, they don't like to call it serverless, but it feels that way. It feels like you're you're running a serverless,

function in the cloud. What were what were those those limitations? Like

cold start times.

Okay. There was a limitation on how much JavaScript you could actually put inside of them, and there was execution run time, limit. I think it was quite short as well, maybe ten seconds, which is pretty long. But when you're pushing up, like, a massive JavaScript file to the server that isn't performing as well as you should I think it should, or you have a slow connection to your database, then you you have issues. And, you know, like, connection pools were really a problem for us as well, because you'd fire up, like, tons of Lambdas.

Every request was a new Lambda if it was occupied, which would be a new connection to the database.

You had to put a connection pool in front of it.

Yeah. It was,

we learned a lot there. It's just that and for anyone listening, Cloudflare uses what's called, like, wall time. And and this idea is is starting to catch on with with other providers as Wes. But, sorry. It's not wall time. It's compute time. Yeah. Wall time is is, like, ten seconds. Yeah. You're you're waiting for a response, and especially with all this AI streaming stuff Wes, I don't know, you're waiting five seconds for a response to come back, You're paying for that. Whereas compute time, you're you're only actually paying for, like, the the actual compute. You're not while you're waiting on IO, you're waiting for a fetch Wes. You're not paying for that. Right?

Like, I mean, this is the wonderful thing about them being a network company. I always say that Cloudflare JS a network company first. They can do that. Like, who can do that? Very few people.

Yeah. Yeah. That's true. I I wanna touch upon, like, Node compat really quickly.

Like, limitations of Cloudflare are that they're not running Node. Js. Right? They're running their own thing called called WorkerD. That's their own JavaScript runtime.

Yep. And they have shims and polyfills, and there's this thing called on JS. And they try to make, like, 98% of Node. Js compatible because at the end of the day, you sometimes just wanna grab a Node package and and use it.

Are there any, like,

limitations or issues you've hit with that? So I I haven't hit that issue myself.

I do understand that it is something that can be a problem, and that's why we actually built Redwood SDK within WorkerD. We were like, let's figure out where this isn't gonna work. But we haven't hit any issues where it has been a problem. There's little things that pop up every now and then. Like,

there there's several HTTP things that are are not totally implemented. But as packages move towards more standards, like, a big one was, like, Axios, for the longest time, didn't have a they used XML HTTP request.

I forget what it Wes, but, basically, they didn't have, like, a fetch implementation under the hood Like an iframe? Warp on.

Yeah. It was it was weird, but they I think with Axios seven, they rolled out, a fetch adapter, meaning that if you use it on CloudFlare, it will realize that there's no XML HTTP Wes on CloudFlare, so you'll they use fetch, which is is good at the end of the day.

So I haven't hit too many things where I I don't have to to sort of work around them. It's it's become much less of an issue as packages get better and as the the shims are are getting better.

Totally. And I see they're they're they're constantly trying to become more and more and more compatible.

And based off using their platform and I'm I'm gonna sound like an absolute fanboy here. Based off using their platform and seeing how solid their engineering is, I think that they're probably one of the teams that can pull it off.

I have pulled it off. Yeah. I'm I'm actually in awe of CloudFlare. I'm I'm really impressed by the fact that most of the time, it just works. It's one command, it releases to production.

Throw an n v error in the front of it, it releases to staging. It's like it's like feels like I'm FTPing a PHP file onto a server. It's so good. Yeah. It's it's really quick. Like, I moved my when I moved to Waco,

my build times went from, like, ten minutes down to like, I'm at, like, two minutes right Node. And then now Wow. V is about to get really fast even faster with roll down.

Yeah. Roll up, whatever the new one is.

It's like rust based bundler, and I think it's roll up. Anyways, whatever the new one is. So maybe it will even get faster. I've been Evan, you've been tweeting out all the stats of, like, some of these, like, four minute build times go down to twenty seconds.

So I'm I'm pretty excited about that. Like, the fact that you will be able to just make an edit to your website and it to be live in, thirty seconds is gonna be amazing.

And, I mean, I I do that. I I know we shouldn't. I'm I know that I should go through CI and should have tests and things like that. I know that process.

Node. Yeah.

So but I just ship to production. I just run it directly from production. Actually, our our website, RWSDK.com, is a React SDK website, and I ship fixes to it constantly using that method. It's so good.

Well, you know what I do? I'll do a little, a little ad read for Sentry here right now JS, no Wes. Just just throw Sentry on there, and then, I I go on to the dashboard and see what what errors are piling up, and I'll go fix those and, whatnot. So, if you do wanna check out Sentry, it works on Cloud for great. Go to Sentry.i0/syntax.

1 more thing real quick. May 29, Denver, Colorado. We're doing a syntax meetup. You gotta be there if you're anywhere within a horse ride of Denver, Colorado. We got the folks from Vercel, the folks from Mux, folks from Century. We're all coming out, of course. We're gonna have Scott there. CJ JS gonna be there. I'm gonna be there. It's gonna be a really great time. If you wanna grab some tickets, they're free, but you gotta get tickets. Go to syntax.fm/meetup.

I love Century.

Yeah. They're it's it's really it's a great great product for figuring out what went wrong.

I see that, David Kramer was actually having a look at a whole bunch of JavaScript frameworks.

And I think that's actually how we got into touch with one another because I was shamelessly plug in regular SDK in his in his in his timeline. And I was like, that thing that you just complained about, we fixed it.

But he hasn't responded yet. So if he listens to the show, Zeig, please hit me up.

I'll show you the light.

Oh, man. Yeah. Please criticize me.

He'll he'll find some stuff, to he'll give it a good run. He's really good at that. So, yeah, I'll I'll, I'll ping him about it as well. Anything else we haven't touched upon about about this stuff?

Yeah. So, you know, I actually think a little bit of the vibe of what we're trying to achieve with the framework JS, like, I was born in the eighties, and I grew up in sort of, like, the personal computing revolution, you know, Mac and PC, competing for people, the Internet coming out. And there's a there was this sense of wonder and awe at this ability to create software.

I use software to impress my friends. And I could do that because it was easy enough for me to understand, and I had, like, really cheap hosts, and I could just FTP it up and things like that. I think that we, with the with the with the advent of AI, are gonna see a whole bunch of people that previously couldn't build software come back to the come to that skill. And, I think they need a really good cloud or really good good platform to host on, and really good tooling that is easy to follow and LLM can reason about, that follows web standards.

And that's partly why we built Redwood, Redwood SDK.

We have this thing, on our website called personal software, and we think that people when people build, software using Vibe tools or generative AI, there doesn't necessarily have to be a profit motive. There doesn't have to be a brand. There doesn't have to be, support metrics and things like that. You just need a itch to scratch and a problem to solve for yourself, your friends, or your Sanity. And it feels like that's the dream of what software was meant to be. It wasn't necessarily just about money. Money's great.

I need it, and I I want it. But I can see in my communities that there are things I can solve with software really easily. I usually don't do it because it's too painful. But now I could just generate a lot of my code, and I can host it super easily. It's not gonna cost me any money. There's power in that. There's power in that, like, just this ability to solve problems using my skills. Yeah. So I'm excited for the future.

And on that, the Redwood starter comes with some, like, cursor rules, which is I thought was really interesting as well

to sort of feed it, I guess, best practices and and whatnot. Or maybe this is just the the prompt. What is this? No. No. Yeah. It is. And we're actually building a MCP server as well that if you Oh, awesome. Ask an agent some stuff, it will understand how to do that in Redoute SDK. It'll exit the alignment as quickly as possible and just do it programmatically.

Like, say, for instance, create a route that has a create a route called ping, and it will just make that for you using, TS morph instead of the l l l l m. So it ends up being cheaper. It understands what to do in a little bit it'll be a little bit faster. What What we wanna do is provide really good tools to AI agents so that they understand what the framework is trying to do. So we're trying to be a really good steward in the age of AI, not necessarily build an AI interface to Vibe hack or I I think that that in that market JS really hard, really difficult to compete in right now. So

Yeah. No kidding. And, like, where JS it at right now? Like, can somebody go and and start building their their next, personal software or startup on this thing? Or, like, it just released it a couple days ago.

Well, it's been out for about a month. We've been working on it for five months. Okay. But we publicly let people know because the GraphQL or the Redwood JS or the original framework, it was becoming a little bit quiet. So we let people know that we were working on something new.

And the week after that, we let them know on the Friday. The week after that was Cloudflare's developer week, and we just got pulled into that, and things started rolling. So from then on, we've kinda said that it's production ready. We have a whole bunch of apps in production.

We are constantly fixing, but, you know, we'll hit one point o really soon. I'm thinking, like, two weeks' time.

I know that there's people on the team that are gonna be like, Node, dude.

Shouldn't have said that yet.

But I that's my gut feeling JS that we solved so many things in the past three weeks. We rely on the web APIs. So the surface area of the framework itself is really not that many lines of code. There JS a lot of heavy lifting happening in the browser and in Cloudflare.

Beautiful. Well, thank you so much for, like, dropping everything and and coming on here to to talk about this. I'm pretty excited about it, and I'm excited to see what what people build on it. So next app I need to build, I'm certainly gonna use this as my base.

Perfect. Thank you. And if you've come across anything that doesn't work for you in the way that you expected or isn't described in a way that makes sense to you, please let us know. I create content around that, and that's what's gonna help me improve the framework for everyone. So

Will do. Alright. Thanks again for all your time. Appreciate it, and, I'll let you go to bed now.