902: Fullstack Cloudflare With React and Vite  ## Metadata - Author: [[Syntax - Tasty Web Development Treats]] - Full Title: 902: Fullstack Cloudflare With React and Vite - Category: #podcasts - URL: https://share.snipd.com/episode/270fdef1-82a9-46f8-a29f-2fda49ced506 ## Document Notes ## Highlights - **RedwoodSDK Leverages Cloudflare Edge** - RedwoodSDK is a React framework built natively for Cloudflare with real-time React server components and zero-cost infrastructure. - Cloudflare's vast edge network enhances latency worldwide, benefiting even rural or underserved communities like in South Africa. Transcript: Wes Bos So the idea with redwood sdk is that it's a what way a framework for building react apps on cloudflare is that is that give us the pitch of what it is yeah yeah so um redwood sdk is a react framework Peter Pistorius For cloudflare it starts off as a vt plugin 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 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 D1 database. You get R2, 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 $5 a month. When we were coming up with the idea for 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 two thousand people where i live and For me it was really important that i could build software that was good for people in my community and i mean good in terms of latency, there are very few providers out there or hosting Platforms out there that have servers in South Africa. And Cloudflare has them everywhere. I think they have something like 230 edge networks. And you know, Cloudflare is a networking company, so they really, really know what they're doing when it comes to making things fast. Yeah. ([Time 0:01:00](https://share.snipd.com/snip/7383db35-fec2-43ce-bcc0-1de024cd9dfa)) - **Favor Transparency Over Magic** - Avoid hiding framework internals by favoring transparency and explicit imports for better control and easier debugging. - This reduces complexity and traceability issues common in highly opinionated frameworks. Transcript: Wes Bos But this is more of like an SDK, dare I say, an SDK that works with the tech that you want, meaning that it's not like you're not burying access to all of these packages that we know and love, Like Prisma or any other ORM stuff or any of the Cloudflare stuff. You are simply, you import them directly like you normally would, right? Was that an intentional decision? Peter Pistorius That was an 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. Wes Bos Oh, yeah, yeah. Peter Pistorius So I was the co-creator 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 Slash response model as well as what made sense from from a typescript position i didn't want to 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 now and i'm talking about redwood js um we had these things called 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 are 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 everything is linked together in Rails. And you started seeing that 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 want to hide that from you. I wanted to make sure you could trace it. ([Time 0:05:03](https://share.snipd.com/snip/d2929d33-0f63-430a-98c6-34cbb362e05b)) - **Use Native Request-Response APIs** - Use standard Request and Response APIs directly for maximum flexibility in handling streams and web data. - This simplifies dealing with things like file uploads or streaming responses without unnecessary abstractions. Transcript: Peter Pistorius It feels like everything is possible. One of my favorite examples is actually uploading files to R2, which is Cloud Flare's answer to S3. You just stream it directly from, you take 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 R2. It's like three lines of code. I don't know if you've ever had to deal with chunks in a multi-part form data thing. It sucks, yeah. It's terrible. It's really ([Time 0:10:17](https://share.snipd.com/snip/52a0952e-ac31-4b7f-8c90-33d5a82104ca)) - **Flexible Database Abstraction** - RedwoodSDK uses Prisma as the default ORM for Cloudflare's D1 database but remains flexible. - Developers can swap ORMs like Drizzle or direct SQL queries without constraints. Transcript: Peter Pistorius You Prisma. So we decided that that was probably the best DX that worked for us, but you're connecting through Prisma to d1 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 wasm that's almost like a meg in size and they are reducing that. They're taking that out, and they're just making it pure TypeScript. So at the end of the day, things are just going to 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 D1 as you wish. Wes Bos But you don't have to use D1. Just run raw SQL queries. Yeah, you don't even have to use that, right? You could connect to anything. ([Time 0:14:35](https://share.snipd.com/snip/a601a5be-ebf7-49a1-b111-4cbc5ae42f51)) - **Durable Objects Explained** - Durable Objects are isolated compute instances that maintain state and reduce latency by smart placement near the user. - They complement RedwoodSDK’s session management, improving consistency and performance. Transcript: Peter Pistorius So if you want to log in a user, you create cookies and that user data is stored in something we call a session. That session is backed up in Redwood SDK by something called a durable object. So a durable object, I actually, I don't think anyone really knows what a durable object is, but I'm going to 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 are logically separated. So in case of Cloudflare, they have this thing called smart placement, where 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? Wes Bos Yeah, yeah, absolutely. They figure out where to put it, because a durable object is backed by D1, and that database needs to live somewhere, right? ([Time 0:16:20](https://share.snipd.com/snip/3e5d836f-fbab-4739-942d-b868f948e9a8)) - **Middleware and Interrupters for Control** - Use middleware and interrupters in RedwoodSDK to modularly control request flow, such as authentication. - Attach small reusable interceptor functions to routes for clear, maintainable code control. Transcript: Peter Pistorius 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 in 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, then we'll call a request handler. But we have this concept that we call interrupters. Essentially, any root 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 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 like, this is how I check if people are logged in. It's a single function. Yeah. And what's really nice about that is when you read the code, when you parse the code, you can see what's happening. ([Time 0:18:29](https://share.snipd.com/snip/15c0debd-77ca-4b7a-be85-60891177c3e2)) - **Fine Control Over Hydration** - RedwoodSDK allows full control over page structure, including disabling client-side hydration per route. - This lets you ship hybrid apps with different interactivity levels under one worker efficiently. Transcript: Peter Pistorius Document an h document that has a head, a title, a body, a div, things like that. The structure of your page. Redwood SDK gives you the ability 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, 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 client-side Hydration and then you have interactivity and then you're getting javascript and react and all the stuff with that and 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 will be like log in and then it flips and it's like nope you are logged In. Click this button. 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 then all of a sudden you get in all the JavaScript that you need. ([Time 0:21:01](https://share.snipd.com/snip/4db7f498-068b-43e5-81d0-cbdb86a6dd60)) - **Bring Your Own Client Router** - RedwoodSDK does not impose a built-in client-side router; you can add one yourself for SPA behavior. - This empowers developers to integrate the routing solution that best fits their needs without forced abstractions. Transcript: Peter Pistorius Router is that true there isn't but you can add one. Since you control the ability to initialize the client-side stuff, you can add one. And actually, I have an early experiment where I took control of the browser's navigation event, and I would actually go fetch the pages from RSC. So I'd have an RSC endpoint that I could hit. I returned the flight data, and I just replaced the contents using the inject stuff in React. So we might provide one that gives you that SPA feeling, but it will be very bare bones, kind of take the same principles that we currently have, that you have full control over it. ([Time 0:23:19](https://share.snipd.com/snip/0ebbaa92-6880-4d50-a4c6-392a964a42b8)) - **Built-in Real-Time React Updates** - RedwoodSDK integrates real-time updates with React server components, broadcasting UI changes to all connected clients. - This creates an effortless real-time collaboration experience without explicit extra code. Transcript: Peter Pistorius So, I mean we implement pretty stock standard react server components like the default experience is the one that we are providing despite the fact that we have like this uh this way To stream chunked 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 react 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 not an explicit behavior but it's one that you can opt into so like react server 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 kind of 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 dips 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've been playing with like party kit quite a bit as Wes Bos Well which is like a real time thing built on top of durable objects. But you're saying that this maybe even doesn't take it further, but like this is the implementation where it's just standard React server component data, but it's also live. Peter Pistorius Yeah, exactly. ([Time 0:26:24](https://share.snipd.com/snip/ff6a4b7d-122f-48fd-a8b8-5f15520e2f40)) - **Real-Time LED Grid with Durable Objects** - Wes Bos shares a project controlling an LED grid in real-time using Cloudflare Durable Objects. - The app mirrors browser drawing directly to hardware with low latency, showcasing powerful real-time use cases. Transcript: Wes Bos 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. That's cool. Peter Pistorius Wow. ([Time 0:28:53](https://share.snipd.com/snip/08fd6a63-ec8a-4a37-b528-8985d2f1f103)) - **RedwoodJS Evolves to Redwood GraphQL** - RedwoodJS pivoted to Redwood GraphQL, unbundling core packages for modular use. - The goal is to let existing users maintain their setup while focusing new efforts on RedwoodSDK for broader adoption. Transcript: Peter Pistorius 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 plugins, take the ecosystem as it stands, and control their own destiny. Will still maintain security patches 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 graphkill uh happen or redwood jays happen it just didn't it didn't find a solid footing in the market and uh i'm here to change that Why ([Time 0:30:00](https://share.snipd.com/snip/d18b84ef-d5f3-4bfd-bc07-b5cf10b355ce)) - **Opinionated Frameworks Need Platforms** - Opinionated JavaScript frameworks struggle because decision fatigue and integration complexity dominate software development. - Platforms tightly integrated with their infrastructure reduce shipping pain and improve developer experience. Transcript: Wes Bos Do you think that was because i am constantly shocked that nothing that is trying to be the laravel the Ruby on Rails of JavaScript has caught on. And I often joke, we're like, yeah, I want something that's opinionated, as long as it's my opinions at the moment. Peter Pistorius If I think about it in my own philosophy, I think the really hard part about building software is not actually writing code. It's gluing together services. And you would feel that like when you were trying to integrate storybook or, you know, like one package in 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 kind of made it possible and uh 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. ([Time 0:31:14](https://share.snipd.com/snip/4d96aa8d-83eb-4353-8ba8-a9ec8d6e7c9a)) - **Cloudflare Beats Traditional Lambdas** - Traditional Lambda-hosted solutions suffer from cold start times, limited execution, and connection pooling challenges. - Cloudflare's worker environment overcomes many of these constraints for better scalability and performance. Transcript: Peter Pistorius It feels like you're running a serverless function in the cloud. Wes Bos What were those limitations? Peter Pistorius Cold start times. Okay. There was a limitation on how much JavaScript you could actually put inside of them. And there was an execution runtime limit. I think it was quite short as well, maybe 10 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 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 i was uh we learned a lot there that's ([Time 0:34:28](https://share.snipd.com/snip/f0904852-fac6-4fb4-ba63-b8b51543e94f)) - **WorkerD Offers Growing Node Compatibility** - Cloudflare Workers run on their own WorkerD runtime with Node.js compatibility through shims and polyfills. - As JavaScript standards mature, most Node packages now work smoothly on Cloudflare without major modifications. Transcript: Wes Bos They're running their own thing called WorkerD. That's their own JavaScript runtime. Yeah. And they have shims and polyfills, and there's this thing called UnJS, and they try to make like 98% of Node.js compatible, because at the end of the day, you sometimes just want to grab A node package and use it. Are there any limitations or issues you've hit with that? Peter Pistorius So 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 going to work. But we haven't hit any issues where it has been a problem. Wes Bos There's little things that pop up every now and then. Like there's several HTTP things that 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 was, but basically they didn't have like a fetch implementation under the hood. Like an iframe? Yeah, it was weird. But I think with Axios 7, they rolled out a fetch adapter, meaning that if you use it on Cloudflare, it will realize that there's no XML HTTP requests on Cloudflare. So they use fetch, which is good at the end of the day. So I haven't hit too many things where I don't have to sort of work around them. ([Time 0:36:25](https://share.snipd.com/snip/c7724e70-bafb-4379-a22b-93ae49baeffb)) - **Direct Production Deploys** - Peter deploys fixes directly to production on his RedwoodSDK website, appreciating Cloudflare's speed and simplicity. - The experience feels as straightforward as FTP-ing a PHP file, encouraging rapid iteration. Transcript: Peter Pistorius We rely on the web APIs. So the surface area of the framework itself is really not that many lines of code. There is a lot of heavy lifting happening in the browser and in Cloudflare. Wes Bos Beautiful. Well, thank you so much for dropping everything and coming on here to talk about this. I'm pretty excited about it, and I'm excited to see what people build on it. So next app I need to build, I'm certainly going to use this as my base. Perfect. ([Time 0:45:55](https://share.snipd.com/snip/3fae0785-2934-4912-a868-c286b343e303))