669: Peter Pistorius on Developing RedwoodSDK  ## Metadata - Author: [[ShopTalk]] - Full Title: 669: Peter Pistorius on Developing RedwoodSDK - Category: #podcasts - URL: https://share.snipd.com/episode/d42d68e6-8e24-478a-a81d-8437861a9a87 ## Document Notes ## Highlights - **RedwoodSDK Eliminates Magic** - RedwoodSDK was created to eliminate the magical abstractions that limited flexibility and developer intuition in RedwoodJS. - It prioritizes zero magic, composability, and web principles, making routing and server logic transparent and consistent. Transcript: Chris Coyier Can you tell us all about that? Peter Pistorius Yeah, yeah, I can. I can give you the lay of the land and tell you how that decision came about. So I've always felt a little frustrated when I was building websites. I felt like I wasn't really focusing on the code that I wanted to write. What I thought I was doing was rather focusing on the framework that I was building in. And it always felt like there were these incredibly rough edges. As long as I followed the happy path in the framework, things felt good. But the moment I deviated from the norm and I wanted to take my intuition as a programmer who's been building on the web for 20 years, I wanted to bring that to the forefront. All of a sudden, it didn't work. Things didn't work the way I expected them to work. And the same was true for what we built in Redwood GraphQL. It just didn't feel right. So we went back to the drawing board and we built a new framework called Redwood SDK. And we laid out a couple of principles for that. The first one being that we wanted zero magic. So no magic exports, nothing that was hidden from you, no crazy abstractions or black boxes. And the second one was that we wanted composability over configuration. So we wanted to make sure that you can build your routes using standard TypeScript and expose those to a HTTP server in a way that felt composable and connectable without having to lose Part of the requests and response chain. And the third one was that we wanted to focus entirely on web principles. And I think we've built something excellent, and I'd love to go over what ([Time 0:03:51](https://share.snipd.com/snip/ee39de7e-3165-4d16-a674-e46c5eadd04d)) - **Explicit, Composable Routing Model** - Routing in RedwoodSDK is explicitly defined in a single manifest file as functions returning components or raw responses. - This design supports co-location of pages and API routes and gives developers direct control over requests and responses. Transcript: Chris Coyier Get to. But if we're sticking with routing, you named that as one of the big three, really. And Dave, you called this out as well when we were talking about it a little bit. It's this like, it lives at source-slash I guess. Dave Rupert And Dave called it Rails-like in a way, but it's just a... A manifest of routes. You're almost expressed like you're saying route-slash call this function. Chris Coyier Call every route as a function, you say. And the homepage does a nice job of calling it out because it's like, here's two different routes, which are strings that just describe what route it is. And one of them returns like a component that you're importing, which feels very React-like. You know, like just pull in this JSX component. And all that route does is return that page, which is like, oh, sweet. And another one right below it is very raw. It just returns a new response. So when you talk about that, you know, embracing kind of web platform stuff, is that what you mean? It's like, if you, sure, you could return JSX if you want, or you can get real, you can get as low level as you want, you know? Peter Pistorius Absolutely. And you know, one of the principles that we wanted to bring to the table was co-location. If code frequently changes together, place it together. And because our routes are, it can be expressed as just an array of a function, an array of routes, you can literally co-locate your API calls and your page calls together in a single file. And then you can reason about them as a contained unit. So you can have your components, your middleware, your server actions or server functions, your routes, all in the same space. And that feels really good. If you have a blog section of your website, just do that. Just keep them in one folder and you can reason about everything there uh you know maybe the blog section has rss feed that it's sending down the wire and you can just write that as an ordinary Response fetch response object and you have that perfect control and you also receive the request not an abstraction of it just the request um so you can pass that off to other servers If you want to uh like if you want a proxy just take the request pass it to another server you get the response back send it back down the wire yeah it feels like you got an amazing amount of Chris Coyier Power with that so how does it it looks like regular old routing in a way you ([Time 0:11:11](https://share.snipd.com/snip/4e8ec8ac-07f9-449a-8d2f-cdeccfcb9a5d)) - **Vite Plugin Tailored for Cloudflare** - RedwoodSDK is a Vite plugin designed for Cloudflare Workers with server-side rendering and React server components. - It leverages MiniFlare, a Cloudflare Workers emulator, to closely match local and production environments. Transcript: Peter Pistorius Okay. So Redwood SDK is a Vite plugin. The Vite plugin gives you server-side rendering, React server components, and it gives you access to a thing called mini flare mini flare is cloud flares emulation environment for Workers react redwood sdk for workers yeah and it gives you database queues um r2 file storage it's a lot it's more than workers okay you can even get ai So like what happens if you use their AI APIs, it will forward it to their servers and it feels like you're coding locally. So it's an emulation environment for Cloudflare. Chris Coyier Yeah, it's pretty sweet. I love that they bought it too. That was a little acquisition nugget from Cloudflare. Yeah, I think some dude did it. And then they had like, you know, Wrangler and whatever. But they, yeah. I did not know that. That's awesome. That's awesome. Yeah, because it's great, isn't it? Like, don't you want that so much? I love the idea that what you're working with locally is what their platform is. So it's like no surprises when you go. Anyway, mini player rules. Dave Rupert That goes to your no magic thing. ([Time 0:14:36](https://share.snipd.com/snip/29c75c9e-e8df-4985-b4f5-07e8fd4f1dc8)) - **Flexible Navigation Modes** - You can toggle between request-response, real-time, and single-page app navigation modes with just a few lines of code. - Use client-side hydration and React Flight data to enrich pages while keeping routing flexible. Transcript: Peter Pistorius A different URL. Or you can serve real-time stuff. So if you want real-time React, you just modify the client part of it. Or if you want single-page apps, you just take over the navigation and you say, okay, when you hit the back button or the forward button on the browser, or when you click on a link, instead Of going to the server and requesting it and doing a whole entire page refresh, just go fetch the RSC component, the flight data, and do a diff on the client side and use a view transition In order to animate what the differences look like. So you can go from request response to real time to single page app by changing like three lines of code. And you don't have to architect your app any differently. ([Time 0:20:37](https://share.snipd.com/snip/a23b2af0-bf7e-44ed-b905-1ee8eef4c768)) - **Use Interrupt Functions for Access Control** - Use per-route interrupters to run functions that can block access or redirect before rendering the route. - Interrupters enable modular authentication and authorization checks to cleanly guard routes. Transcript: Peter Pistorius And then we also have a concept called interrupters, which can run on a per route basis. And what that looks like is on a route, you can define a function that returns a response. But you can also associate an array of functions to a route. And then if either one of those returns early, that interrupts the flow of what's returned. So as an example, you could create an interrupter that looks to see if a user is authenticated. If they're not, you return a response that says, hey, you're not authenticated with the correct error message, and then a header to redirect them to the correct page. So they will not get access to the last page, which is the one that they were trying to access. They'll get interrupted and forwarded to somewhere else. Chris Coyier So each route is an array of responses and array of functions in whichever one. So what if it doesn't return the middle one? Then it's just like, oh, they were authenticated then. So move on to the next function. Yeah, yeah. Peter Pistorius And what's great about that is you can pull out that require authenticated function, stick it somewhere else and reuse it throughout your code base. So then it reads as if this requires a post. The user should be authenticated, et cetera, et cetera. And then they'll get the final response. Dave Rupert Can you read? I assume you can redirect after that if somebody's not, if not user or context.user new response login page. How does that work? Peter Pistorius Totally. So on the response, you can set a header that provides ([Time 0:22:50](https://share.snipd.com/snip/bcd7e60c-4c5d-4b7b-87ec-fa3fc803fe7f)) - **Avoid Magic in Exports** - Avoid introducing framework-specific magic exports that break TypeScript and JavaScript language contracts. - Build frameworks that surface all code logic explicitly to aid maintainability and ecosystem integrations. Transcript: Peter Pistorius And it's got rules and you understand them. Then along comes a framework and it says, hey, forget those rules. We have this thing called a magic export. So export this thing with a certain name and we'll hook it up for you. Don't worry about how it happens in the background. That's not your concern. And you, the user, cannot reason about how that got on the screen unless you read the docs. You could imagine, but you're not able to look at the code and decipher that yourself. And there's no like command click on a thing to see where it goes. You're like, somehow this loading indicator or this error page or this data, like the data gets into my components somehow. And that didn't feel right to me. I really wanted to surface the parts of the language that were real, the contract that you've subscribed to when you learn TypeScript or JavaScript. I wanted to make sure that you could reason about everything you were building, just using those ideas, not someone else's ideas. And yeah, I think that's really important. Chris Coyier So is that the difference? Is that the, because there's a little bit of why here, right? There's like, we did one thing and then that's over now. And we're doing it all over again, which I think you said is a unique opportunity to ([Time 0:32:35](https://share.snipd.com/snip/7dec231a-9b10-41d1-a59c-0fea4061410a)) - **Design for Low-End Devices and Economy** - RedwoodSDK's principles are rooted in serving users with limited devices and bandwidth, focusing on minimal JavaScript and free hosting. - Choosing Cloudflare as the exclusive platform ensures fast global performance accessible to users worldwide. Transcript: Dave Rupert Shaking true so lots of there's lots to think about at this level that you're operating it i think is what i want to say and you know i we we set out with these principles and we wrote them Peter Pistorius Down and they come from a place where I am geographically located. The principles are informed from where I am right now. I'm in South Africa. We have really poor people and really rich people. I think we have the highest income disparity in the world. We're catching up. Don't worry. Well, then what I'm about to say is going to resonate with you. So people here don't have very good mobile phones. They have mobile phones. Everyone does. The networks are also pretty fast, but bandwidth is expensive. And so is memory on phones and phones are slow. They're not the best things you have out there. So we designed this framework with these principles in mind in order to deliver the least amount of JavaScript, the least amount of, and consume the least amount of bandwidth possible. And we picked Cloudflare for a very particular reason, because they have 330 nodes throughout the world. And they're free. As a hosting provider, they're free. So people in my backyard that want to build software for their community can. They can just build the thing that they care about, host it on Cloudflare, and their consumers of that software will have a good experience because we've reduced the JavaScript requirement Of the framework how we got to that was through these principles that we've set about and the principles inform every decision that we make so we don't integrate a third-party package From a profitable company from a from a startup for instance we'd rather give you WebAuthN or PasskeyAuth or username or passwordAuth. If you want to use something else, that's totally fine. But we don't want any of our users to have to pay $20 to subscribe to a SaaS or even to pay money to host. Because we want the majority of the world to be able to participate in software. And I think with the advent of AI, more and more and more people are going to come to the forefront building things. And they need really good solid principles in order to understand how things are flowing through the code. And the hard part, if software isn't the hard part anymore, then maybe hosting it is, maybe deciding which database is. There's a lot of decision you have to make about, you know, which database am I going to use? Which queue provider am I going to use? Where am I going to host these files? We took all that away and one command and you get it all. So if it's fast for us, it's going to be fast for you. And there are optimizations that you can introduce, you know, single page ([Time 0:38:34](https://share.snipd.com/snip/cb7e722c-3bcc-4dfe-a6e0-b6386a1db685)) - **Cell Pattern Removed for Transparency** - Redwood's cell architecture that managed loading and error states was removed for simplicity. - Such abstractions hide control flow and limit flexibility for developers deviating from typical patterns. Transcript: Peter Pistorius Was configured. But the problem was we abstracted that away from you. So if you wanted to deviate from that or you just felt like something was a little bit different, that file, you could not get to the logic that was picking the right part at the right time. It was completely hidden from you. So what we could have done was just surface that to you, given it to you as a file, and then you just wrap your components in this function and you know maybe use a key value pair or something Chris Coyier Oh i see like you could replicate the concept of it in your own wrapper component class we don't talk about those anymore go ahead go ahead everybody else uh the light years ahead of me Peter Pistorius Is it a class with a k or with a C? Dave Rupert In React with S. Peter Pistorius Oh, man. I do miss classes. React classes. Dave Rupert Hey, I'm with you. The dream is still alive. Because that's magic, right? Because it had to be like blog post, sell, blog post, sell, loading, or I forget the name, naming convention. But you had to have these magic sort of names to my cells, correct? Peter Pistorius Yeah. It'll come back someday. Somebody's going to steal that. You know, I could see it being in. It's in Next. It's in Remix. They all have this concept of export something that has a particular name and will connect the dots for you in the background. Dave Rupert Yeah, okay. Suspense is ([Time 0:54:38](https://share.snipd.com/snip/c6525864-40c0-438d-9bac-9f9ebf5f93fe)) - **All-In with Cloudflare Platform** - RedwoodSDK focuses solely on Cloudflare to streamline user experience and infrastructure. - This exclusive platform choice simplifies deployment while providing integrated access to databases, queues, and AI services. Transcript: Dave Rupert That you're going to run into. But I think it's maybe not a Redwood level. I think it's maybe like a React level thing that should be concerned. You know, like that should exist somewhere. Totally. Whatever framework that bakes in a X state state machine, but feels less like X state. I like X state. Chris Coyier We have all the evidence we need that we all refuse to learn state machines. Dave Rupert It's not happening. But if you force us to. So you have to, but you have to, yeah, you have to like gaslight somebody into like using something cool. Chris Coyier That's accidentally a state machine. Dave Rupert That's accidentally a state machine. Chris Coyier Yeah, I don't think that that's going to be us. Yeah, probably not. Dave Rupert I am curious what's been the community feedback. You did a major shift, a major pivot to a whole new idea. Is the community following you? Are they middle fingers? Peter Pistorius Are they, how's that been? It's a little bit of, a little bit of some of that and a little bit of some other stuff. Like we are receiving a tremendous amount of love. People are surprised by what we've built. They're like, I would say smitten is a really good word to describe the feelings that people have when they use Redwood SDK. And of course, there are people that are not happy with it. Is our strategy to support Redwood GraphQL long term and to make it so that you can get off Redwood GraphQL itself and then own those parts yourself. I don't want to put anyone in a situation where they're feeling completely trapped. But the reason why we shifted from one to the other was because growth had stalled and it wasn't sustainable. And we needed to come up with a new idea so that we could, you know, find the new thing that was going to make sense for the way the web is developed today. We started Redwood SDK five years ago, and it was built with AWS Lambdas in mind. And that technology really didn't go anywhere. It didn't get to where it had to go. It kind of stalled. And that was a bet that we made that didn't pan out. And I think that's part of the problem. You make these bets on technology and technology evolves. You've got to make sure that you have enough flexibility in what you've built to evolve with it. And the shape that we have right now feels that it is that thing because it focuses on solid principles. Yeah. And you have one possible buyer and they're probably going to be interested. Yeah. We'll see. That would obviously be very exciting, but we have, I think a really good plan towards monetization that isn't hosting. I can, I can tell you exactly what it is. If you are interested. Chris Coyier I'll drop it. Yeah. Yeah. Dave Rupert Second surprise. ([Time 0:57:28](https://share.snipd.com/snip/b96984d2-e557-4f2e-92c2-6a43f84091fe))