Peter: the browser is the framework, and the network is the framework. If you understand the fundamental slash re response cycle, you can build anything very quickly and it'll be really easy to reason about. So that's the number one. We wanted to focus on fundamentals
[00:00:26] Introduction
Andrew: Hello, welcome to Dev Tools fm. This is podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host Justin.
Justin: Hey everyone. Uh, we're really excited to have, uh, Peter Pistorius on with us today. Hope I said that right. Uh, Peter, big fan of your work, uh, have followed redwood js for a long time and, and incredibly excited about Redwood SDK. Uh, so. We're just really excited to jump in and talk about this. But before we get started talking about Redwood, would you like to tell our audience a little bit more about yourself?
Peter: Yeah, sure. Thank you Justin. And you know, your excitement is. Is really fueling, uh, our, our enthusiasm for what we're building. So thank you for, for being there and, and trying things out and, uh, giving us encouragement. Um, so my name is Peter Pretorius. I am South African. Um, a couple of years ago I worked for a startup called Chatter Bug with Tom Preston Warner. And whilst I was there, um, we started a framework called Redwood Js. and I worked on that for a couple of years. And then I went off and started my own startup, which, which failed. And I closed it down then Tom, um, I would take over leadership of, of Redwood. Uh, so we spun that off as a separate entity I'm now the CEO of Redwood. Um, and we pivoted into a new product called Redwood, SDK. And that's what we're here to talk to talk about today.
Andrew: Yeah, a lot to unpack in just that one. That one sentence right there.
Peter: It's been a, it's been a crazy couple of years. The last five years have been insane. Uh, not only just COVID, but also, you know, It's been, yeah.
Justin: Yeah, maybe one thing to front load.
[00:02:10] Challenges and Vision for Redwood SDK
Justin: Usually we sort of like talk about this stuff like later on, but you know, you mentioned you're the CEO, this product, Redwood, SDK. we've, we've talked to a lot of, uh, people who are building products around open source tooling and open source software, and there is some fundamental tension with like. W working a lot in open source and trying to have a monetizable product. And I'm curious like what your vision of like redwood the business is. Um, still wanna talk about the framework and maybe give people more context about what we're talking about, but it is still interesting to hear. It's like, how do you think about like balancing open source and, you know, bringing in revenue.
Peter: fair. You know, the thing is, is that sometimes what happens is, is like a bit of a, a rug pool. people will build an open source project and then you'll figure out how they monetize it much later, once you've invested time into it and that. It just doesn't resonate with maybe the ideals of the project that you were, that you were invested in.
Um, and if you have a look at Redwood SDK's website, we have this this idea called personal software. Um, and we're trying to sort of create a movement around an alternative way of, of building software, which is really, uh, software that you build for yourself, your friends, or your family to scratch an itch. That isn't necessarily about building a brand or figuring out a monetization strategy or raising VC funds. Uh, and our, our tagline is actually, this could be the start of something small. So with all that that I just said, we're kind of like we're encouraging people to build software using open source tool that doesn't have a monetization strategy and isn't necessarily something that they should go, they shouldn't necessarily go raise VC funds. And we got money from Tom Preston Warner and Preston Warner Ventures, and we're, we're building Redwood SDK, using his money. Um, so the monetization strategy that we have right now is we're gonna build a store source code so if you built something useful, um, and people like it. you don't necessarily wanna come up with a brand or a monetization strategy or wanna it, can just sell that source code on our store. Um, people will pay you a yearly license. They'll get access to the code, they can modify it themselves, and then they can run it in their own, uh, personal CloudFlare instance. Um, and that's sort of where we are right now. We're trying to, I like to think of it as steam for source code. Let's see how that goes.
It's concept.
Justin: That's super fascinating. Um, maybe before we like go further, let's just like dig into redwood. So Redwood started as redwood js. Uh, so can you give us a little bit more context about like technically, like how redwood JS was shaped and sort of like what its ideas were?
Peter: Yeah. Yeah. So really it started off with a tweet like all good framework, should Tom, uh, shared a tweet by the netlify. team they had this new ability to kind of like drag and drop a GitHub repo onto a and they would automatically boot up a website, uh, Net's infrastructure. when I saw that, I said to Tom, that's really cool.
Um, it's such a cool, it's, it reminds me of the old days where we could like F-T-P-A-P-H-P file onto web server, and then you have like something live. And, um, that was backed up by a technology called Lambdas, um, by a AWS. we thought it would be really great if we built on top of that infrastructure.
Um, in the, in the, in the five years since we've launched Redridge Airs. I don't think that Lambdas have changed at all. Uh, they've changed very, very little. Uh, they haven't improved. And it was our, our assumption was that this technology will get better over time. So we created a monorepo inside that Monorepo.
We gave you a server side we gave you a client side. Um, and then the one we'd ship to the CDNA net fly, CDN and the other, we would ship to an AWS Lambda. we very quickly ran. I ran into a lot of problems with that. Uh, the first one being that the moment you wanted data, uh, you needed a connection to a database. And because there were lambdas, they would, they would spin up, a new one would spin up for every request. Um, uh, and you'd get into connection pool errors and there was latency errors and called start errors. And I think we were too early for what we wanted to build. Um, and the difference is with redwood SDK. We to go all in on, um, the request response model. So we went back to the server, uh, and I wanted to find a platform that was, that included everything you need to build software. So I really wanted you to focus just on the software you wanna build rather than the infrastructure that you hosted it on. I went looking around for a platform that could do that. Um, number one, my number one requirement was that it was worldwide. So, I'm in South Africa. If I'm building software for my friends, I want it to be fast for people around here or my community. And I want the same to be true for you in New York. Uh, and I want it to be free, uh, as well. I want it to be able to try it without having to pay. Um, 'cause you might not actually have access to a credit card. I think of myself being ambitious teenager to get things on the internet and. Back then I could, there was just like free PHP servers where you could host things and I'm sure there, I remember there was something like that for Node in the early days jitsu or something like that, if I remember correctly.
But I don't think that exists anymore. And you're kind of out $20 if you wanna host something and then you need a database and then you're out another $20. So my idea was let's find a host. I found CloudFlare. They had I think like 330 nodes all over the world. You don't need a credit card to use them. And they just happened to include like a database, um, cues, file storage, like practically everything you need to build software. Um, the fundamental parts, and then like lots of bells and whistles. So we prototyped on CloudFare for about a month. And I'm sort of hyper cautious of technology. Uh, you get upsides and the upsides always produce downsides. with CloudFlare, I haven't found them yet. And I know that sounds ridiculous and I'm sure they exist, but it is a really, really good platform. Um, so. The separation between, uh, redwood js and Redwood SDK couldn't be further. The one is purely server-side. It gives you server-side rendering with react server components, um, and, and client components.
And then it gives you access to the CloudFlare platform, um, with database storage queues, et cetera.
[00:09:10] AD
Justin: We'd like to thank work os for sponsoring today's episode of Dev Tools fm. When you're building a SaaS product, integrating enterprise features like single sign-on directory sync and audit logs isn't just a nice to have. It's often the unlock for your next stage of growth. And that's where Work OS comes in.
Work West offers a developer first platform that makes adding enterprise functionality feel like any other modern integration. They have SDKs and most popular programming languages and a well thought out API. It's really easy to get started with and easy to stay productive. The docs are genuinely great.
They're very clear, very example driven. Built to get you from zero to production very quickly, and you'll find helpful guides for most common integrations. So it's really great for getting, you started serving your first enterprise customers and they have a ton of extra features. Everything from domain verification to fine grain authorization, and it's all built with developer experience in mind.
So if you're looking to serve bigger customers without drowning in enterprise infrastructure work, definitely. Give work os a try. That's work os.com.
Yeah, it's interesting. So I first heard or not heard about Redwood, I, I guess, but was made aware of it by my, uh, friend Orta the Rocks, who I worked with at, Artsy and Redwood Js. Had I. An architecture that was very similar to how we built things at Artsy. So, um, react GraphQL. Um, Orta is a, a big fan of Relay, so like Relay was, was pretty much regularly in the mix.
And, um, this is like how I thought about web architecture a lot. And there was like a lot of products being built at the time like that. Um, and then seeing Redwood, SDK. What's server components, uh, being very closely tied to CloudFlare deployments, and it does seem like the, the overall architecture in some ways has gotten a lot simpler. what what were the lessons that led from one to the other? Were there like, particularly like complexities and pain point, like, you know, why not keep using GraphQL? Like why just leaning to React server components? What are the implications? Like, how did you get here?
[00:11:19] Principles and Philosophy Behind Redwood SDK
Peter: Yeah, so we have a couple of principles that we, we invoked when we wanted to build bread with SDK. Uh, but the first thing that I really think about as a, a developer today is that a lot of what we do is we share memory from one computer to another in a safe and layer you introduce, um, when you're doing that. Adds a layer of complexity. All of a sudden, you need to authenticate in this particular layer, if you think about it, your database is a computer that has memory in it. You need to authenticate against that. Then you include GraphQL or an ORM. Then you include GraphQL, and then you include some kind of HDTP transport, and each one of those has like its own abstraction. Um, that allows you to do the share memory securely, those abstractions add up, and at the end of the day it, it feels like you're not actually coding on the web anymore. You can't actually really fundamentally understand how things are going over the wire, and I think it just makes the experience a lot worse. with with Redwood SDK, it's request and response, um, it's fetch all the way through and. CloudFlare has this concept called bindings. So a database is, is accessible to your worker through a, a variable. And, um, it feels like you're, it feels like they're on the same machine, so it feels like you're not sharing memory of the network.
You're just saying, Hey, gimme this stuff in the database. Um. That gives you sort of like, it, it, it also makes building software much simpler because we're using the, the browser as the framework, like we're using form data request and response streaming responses, upgrading, uh, fetch requests to web sockets, et cetera, and it just works really well.
Like that. The people who architected the net really knew what, what they're doing, they still know what they're doing. They've designed something that's incredibly elegant. I think that we have abstracted too much of that away in the way that we approach building websites today. So I have this thing that I say, the browser is the framework, and the network is the framework. If you understand the fundamental slash re response cycle, you can build anything very quickly and it'll be really easy to reason about. Um. So that's the number one. We wanted to focus on fundamentals. Uh, number two was we wanted to remove magic. When you give A-A-A-A-A framework developer a a er, they're gonna invent some fancy syntax.
'cause like, Hey, here's a, here's a, here's a nice to like remove some boilerplate. If you a in or like you, you include some named exports. We will what a special way. But all of a sudden, you start breaking the contract of TypeScript or JavaScript, you're no longer importing and exporting. Explicitly, you're doing an so you can't follow the flow. Somehow those things appear on the page like as if it were magic, and then you figure out how to type those things in those magic gaps. So you have a client side component and you have a server side component or function. I. And you're like, how do these things, how the work together?
Then we invent TRPC or you know, something along the lines that just how gives us the typings with, uh, with redwood SDK, you import the function. It's typed the client component. It's typed, we're just leveraging TypeScript. Um, so I wanted to remove all the magic. I wanted you to feel like you were coding. TypeScript. Um, and then the third thing was we really integrated a lot of packages with Red Witch as we had storybook and jest, and we had all this magic around how they were working and invented our own syntax. So we made sure that that syntax worked and storybook and, and jest, and made things really difficult to maintain. was, upgrades were a nightmare for team. Um, and things just slowed down. We couldn't, we couldn't move as fast as we wanted. Um, with Redwood SDK, we're not that. We're just a v plugin. stock standard, if you want to integrate something, we'll provide a really, really good guide on how to do that, maybe your AI can figure that out for you. we want to put the power in your hands so don't feel locked into our platform either. So. I've said this a couple of times myself, I'm really surprised with what we've produced. feels elegant to me and I, I do not know why other frameworks aren't like this. I dunno why it took so long to get here. but I have this, like, I thought about this and there's this picture of these Space X Rockets. I've got that like Raptor version one, Raptor version two and three. and every iteration they get simpler, but they're doing the same thing. And I feel like. of what happened with here. been able to a, a production, a framework twice my life. I don't think that that's something that a lot of people get an opportunity to do. And the second time round, I've learned some lessons and them to the, to the, to the table.
Andrew: So the, the concept of no magic, I think a lot of people will, uh, resonate with, uh, I feel like that the first request, response, like player in the game was like remix and like leaning into those web fundamentals was a big part. Uh, but one thing that kind of like. Sticks out to me a little bit is that Redwood SSDK is built around RSC and all the stuff you said about magic and like just the things happening without the developer knowing I'd say do apply to React server components.
'cause they are kind of like a very new thing. Require deep bundler integration to get right and do kind of hide a lot of magic that's going on. So how does that like kind of play into that, that ideal?
Peter: So I that I don't really see the magic anymore, anymore I've implemented, implemented RSE twice now. Um, I. So really RSC is request to server. Um, if, say, say for instance, you're running an action, man, I could be really wrong here. And like someone's like, Nope, that wrong. This is my current of RSC. Um, so say for instance, you have a client component and you wanna perform an action, uh, you click a button, the action gets executed. Um, that center, uh, a server over fetch. It has like a whole bunch of at the back of the URL. So it'll be like, uh, a local host 8, 9, 10, uh, question mark rrc action, then it'll have a whole bunch of data. Um, your server will pick that up and it'll say, Hey, oh, this guy's trying to perform an action. Um, it'll break it apart to figure out what the action was that you were trying to perform, and it will run the function. and then it will return the response of that function. Along with the newly rendered state, of the page that you're currently on. Um, then that gets diffed on the client and then you get the new data. So to me, it actually seems really simple and it's also based on of how we're building software request response. Um, and the state is just pushed to the server. That's your source of truth. So from my perspective, it feels. Really easy, better to build software in, in, with React server components than it, than it has felt to build it with, with other things. Um, yeah.
Justin: A, this is an interesting area for me. I
[00:18:52] Developer Experience and Future Plans
Justin: 've spent a lot of time in the last several years working on APIs coming from like a front end full stack perspective, and TRPC GraphQL and REST APIs and you know, basically everything else. And there are some like. challenges building an API for like, there's this concept of backend for front end, which like people are moving more and more towards.
So I think like things like next JS and re max and all these meta frameworks are sort of like backend for front end. You're writing like these functions that are exposed directly to your front end code. like getting them right can be hard. You need sort of like a good meta framework experience in a lot of cases just to make it like easy to reason about, um, and. are some, you know, rrp C libraries, like TRPC and they just have so much bowler plate and it's like kind of hard to wrap your head around. So it's like, interesting thing for rack server components to me is that you're exposing, you're essentially exposing RPC interface in a way that like is ostensibly simpler, you know?
And especially when you're thinking about the encapsulation of like. end code and, and server code in this like one component graph. I, I still think there's like more UX work for the React team to do though, because it's like, there are these situations where you get into that are just kind of awkward.
It's like, oh, where you're trying to use a client component or a server component in this like client component context or something. I don't know. There's like this situation where it starts breaking down and there's still some UX things, especially around like. I dunno, just giving good errors, like helping people understand the modality, like how to think about these things.
And I think that'll be a thing that everyone building on Rex server components, including redwood, will have to like grapple with a little bit. It's like how do we. Really educate users on like the data flow and how things are happening. Even it's like one though where like seems simpler, you're like writing less code, you're doing less extraneous types, there's less boilerplate. You're getting closer to the point of just expressing what you want to have happen and it happening, which I think is the ultimate goal with all of this is like choosing the right abstractions. Not to have to write a ton of code to do a really simple thing, but I think are still there where it's just like.
the UX still, UX and DX still need a little of, bit bit of pushing there. I think that's a React ecosystem thing.
Peter: I think that's totally fair. And you know, those things have tripped me up as well. And I'd be like, uh, we also have a Justin, our, on our team and I'd, I'd Justin, this just isn't working. I think we have a bug. And he's like, Peter, you're doing it wrong. actually PAing a, you know, you can't use a server component like this.
And I'd be like, oh, of course. Okay. Yeah, yeah, yeah. Let me try and remember this for next time. And then it tripped one of our other team members up, same error. And I was like, oh, I've seen this one before. is what you're doing wrong. And he is like, ah, okay. So you're not wrong. I think we can improve that definitely.
Um, and I think the fact that there's mysticism around it is probably not a good sign. And this is why we are entering the conversation with the React with, with, with Redwood SDK. want to clarify what's happening and make it easier to understand, without all those layers of abstraction, that just feels like you are not. just a normal network request. so yeah, this, that's our goal is really to bring rack server components to the, to, a, a group of people that wanna build simpler software.
Justin: I think the nice thing about this approach and the thing that's really attracted me to Redwood, which I'm like. a bunch of stuff with Redwood is ski right now. I think the nice thing is just that it's, I'm learning more about React and I'm not learning more about like some other RPC framework.
You know, like
That's good. That's nice. I like that.
Peter: yeah, yeah. And you know, I this like really spicy hot take that I, like to share, which is like, you have a limited amount of time on, on earth and you're gonna spend that time learning something. would you spend it learning some big corporate tools and, you know, you can Facebook or Meta is a corporate, uh, Redwood, SDK, Redwood JS is a corporate. you know, we're not gonna try and sell you $20 a month hosting. We want to enable you to make a living software you're writing. And maybe we take a cut of that so, you know, learn our thing. It, it is an an abstraction. Uh, it's really gonna give you a fundamental understanding of how the web works and you can use that anywhere.
Um, yeah, that might not be true for other tools.
Andrew: Yeah, it's weird when you start leaning into like the, the browsers capabilities, like when you haven't for a very long time, like I've been a web developer for. For 13 years, and I didn't learn about how form elements worked until probably like four or five years ago. Uh, now it just like, it sticks with me and I try, I try to lean into that and it's way better.
But like we have lived through an era where like almost everything about the web platform was, uh, abstracted away.
Peter: Totally, totally. I remember like trying to upload files some kind of like jQuery plugin that somehow gave you a progress bar. And it was, it was wild. Uh, and I, you know, I was super surprised to see how easy it is to upload a file in, in, in Redwood SDK, like, create a form, push that form up using fetch. Grab the file out of the form data in the, in the server handler and just stream it directly into R two. It's like four lines of code, and then retrieving it and sending back to the client is the same, same operation, just reversed. It's just fetch and then you're just streaming it the wire. It just feels so right.
You're like, someone really through. It wasn't me. I gave you it with.
Andrew: Cool. So, uh, you built this all around CloudFlare and that seems to be a, a central thing that is very important. Uh, do you expand to, do you plan to expand it to other platforms in the future?
Peter: Uh, right now? No. I think, you know, one of the problems that we had with redwood is we on and I wanna make a, a, a group of people really well. I think Cloudflare's positioning is, so unique and so important in, in, in the, in the hosting world today that it, I don't think there's a downside to using them.
You know, I can, I can take, put on my tenfold hat and think about scenarios where it would not work out for us or anyone trying to build on CloudFlare, but I just don't think that those are realistic and it's not something I'm gonna worry about, right now. And you shouldn't either.
Justin: Yeah, that's, I mean, CloudFlare is such a good platform. It's, yeah, it's really, it's really coming into its especially own it seems they're having a lot like at Traction.
Peter: Yeah. They, they have a, I. like
really solid engineering culture. It's surprising, like I'm surprised that I didn't get into it earlier. Um, it feels like where been all my life.
Justin: So, uh, there's something else I wanted to talk about. So you, you'd mentioned this earlier, redwood js, um, the original framework, lot. stuff built into it, you know, it's providing a lot of direct integrations. I'm doing a lot of custom things those integrations, and it made your velocity harder. and so now you're, you're. Building Redwood, SDK to be a lot more modular, a lot like smaller core, trying solve less to all upfront. Um, but you also have this goal of like, oh, well we want people to build like personal software. We want it to make it like easy and understandable and like let you solve the, the goals that you need to solve right away.
So it's like how do you balance the tension of. Baking things in because it's easy and people don't have to think about it. You can just be super opinionated and say, here's how you do X, versus like, we don't wanna overload this with a bunch of complexity. and maybe we wanna give people the flexibility to use whatever is appropriate for their use case or, you know, whatever it may be. What's the balance between that and how do you think about like, putting things into core versus like, not.
Peter: So for us it pretty much hinges on, uh, the browser. If the browser offers something that can do what we want it to do, we will lean into that. Uh, and I'll give you an example, like with sessions, just using cookies and we're using cloudflare's durable objects, um, to store that session information.
And then with authentication, we also provide, uh, web orth and. that that's a, a really, really good solution. That's future proof, but you can use anything you want yourself. It's just that we're not handing that to you. I, I, you also, if it's a, a commercial entity that's offering kind of service, I'm very cautious of including that.
Like if you have to configure it using some sort secret key, I'm probably not gonna add as a default in the, in the, in the. the SDK, and I'll tell you why. The reason is like, uh, my brother is learning how to co program. He's a technical guy. He's always wanted to code. It just didn't work for him. couple of months ago, he came back, came to me and he's like, Hey Peter, I built this thing. And I opened it up on my computer and it was a webpage. was like, what? How did you He I used this thing called Cursor. I was still coding back then. I used this thing called Cursor I, and like I just, it could, I could speak to it and it could speak to me in a way made it understandable. And I was like, where's this hosted? he said, it's on Versal. And then I said, your database? And he says, it's neon. And I was like, whoa, how did you make these choices? He's like, the AI made it for me. And I was like, interesting. It's like, but it, it's costing me money. And I okay.
Interesting, interesting. And he said it was also really difficult to go from to production he didn't really understand the security implications of that, that connection between and his, um, neon database. I was like, okay. There's something here that whenever you are connecting to an external service and you have to provide an API key, or, uh, actually, let me back up a little bit.
I like to think of it as if you're paying five taxes. So number one, you wanna choose an authentication service. You go on the internet, you do a bunch of research, out which one resonates with you in terms of price and brand and you like. you sign up, you give them your credit card, you. Learn what the API does. You make it work locally, then you make it work in production. Those are five different taxes that you have to pay before that service is actually usable your day-to-day flow for building software. I don't want that. I think that that's the hard part of what software nowadays, is connecting all these services together.
So if you have this just cloud player binding where it's actually feels like it's on the machine that you're busy coding on, um. feels like magic. And in the local development environment, uh, CloudFlare has provided an emulator called mini flare. And Mini flare gives you access to database, durable objects, queues, even ai.
So you give it your CloudFlare account when you sign in with Thing called Wrangler, and then you can access all the AI models in your local development environment and you ship it to production one Command. P-P-N-P-M release. it's live and it's working. like that was the most surprising thing for me, that when I shipped to production, it worked.
But what was even more surprising for me was that I was surprised by that. like my expectation should be that it just works. I've been sort of trained, in my, in the last, like years of my career that shipping to production means you're shipping something that's breaking and then you subsequently try and fix it. that hasn't been the case at all with CloudFlare. I'm like, whoa, it's working great. It's a great experience.
[00:31:10] Ad 2
Justin: This episode is sponsored by MailTrap, an email platform that developers love. Go for high deliverability, industry best analytics, and live 24 7 support. You can get 20% off for all plans with a promo code dev tools. Check out the details in the description below.
[00:31:26] Redwood's Plugin System Vision
Justin: Something that I think will be really interesting for y'all figure to probably with kind of how you've talked about this conceptually, is Redwood is gonna need a really good plugin system more so than like anything else. And to. Let's talk about the, the auth, for example. So, um, you have auth configured and your standard, uh. Example, starter kit or whatever. Um, so that comes through, that sets up the durable object, has all these things. Um, but it's just like, you know, it's like ejected code. It is like just code that lives in the thing. It's like, it's a template, right? And so if you're thinking about that changes under the hood and how y'all, like, you're adding new features to it or whatever, like people aren't getting that. And this is gonna be one of the interesting things for you to solve because you're also thinking about like, oh, well we want you to like. Be able to sell functionality. so just be interesting to see how you, uh, approach Um, and just like, it's I, I have a, a personal project that working on right I'm for like social good essentially, I'm using Redwood SDK, and, and I chose to use Better which is an that's like Compete with like clerk and a bunch of these other services that are doing off, but they're just like, we're just open source. You on your user's table, here's, you know, this thing. Integrate it however you want. and my experience integrating that with, with Redwood has been really positive. And I, and I think this will be the, again, it back to goes the interesting can figure out how to like package up and make these things configurable, then you do have that opportunity to sort of like. Cell plugins and extensions is a sort of a meaningful, uh, mix in to an existing application, but it also give you the ability to like keep redwood SDK core really light, which I think is gonna be super critical for y'all going forward.
Peter: Totally. Um, so I, I, I mentioned earlier that we are thinking of this store for source code. one of the fundamental ideas I really love about React is this ability co-locate things. components, your styles, um, you put them together, if the code changes frequently together, keep them in the same space.
I think. Ken see Dot said that, um, and one of the things that really frustrated me when I was building websites was you would have your components on one side. Their styles were alongside them and then you have API routes and they're like completely off in this other place. Uh, and that's, I. Uh, you, it just feels so disjointed.
You're like, the, these pages speak to this stuff here, but they're no, they're nowhere near each other. So with Redwood SDK, we give you the ability to co-locate your API routes and your JSX routes the same. In the same file. Um, and you can export that just using, uh, an array. So you say export const routes equals an array, an array of routes. And then when you plug that into your, into your worker, you use prefix and then you supply those routes and then it will, it will prepend a string at the beginning. Um, and then we also give you the ability to control the document. So the root element of what, where your Js X components are rendered, you can control that.
So with Redwood SDK, you can turn off react if you want to, you can turn off client side, uh, hydration. You can just send HTML down the wire. Um. Or you can turn that, uh, that, that, that react fetch interface into a real time interface with durable objects. Um, and we actually supply that as, as something that you can do. So, like really have control over every bite over the wire. I. We're gonna introduce something called add-ons that give you the ability to plug in like a forum or comments or, I don't know. I'm, I'm, I used to be a Jango developer, so they had this, they actually had something called add-ons, contribute add-ons, you could bring stuff into your, into your, into your website that were contributed by other people.
And I've never seen that pattern repeated, uh, in a JavaScript framework. Maybe it does exist, but we're gonna make that something that's first class. That feels like you are in control, um, of the actual source code. Uh, and we will probably leverage in order to help you do that, like an MP MCP server and AI to bring those things into your, into your stack. and then you have the code there and you can modify it, like, kind of like shad for, shared for, what would I say? Shared for sections. I dunno. Yeah, the idea. So, I mean, glad you because something that I'm super excited about. It feels like, why am I, why am I reinventing these things?
And I want to use them a package, that's also not really possible. I can't bring components and UI and roots and all that other stuff, so we need something else. Yeah.
Andrew: That's a, that's a super interesting idea. PPL, plugins like that. I, uh, it doesn't feel like it's something that's been explored. Uh, in general. It seems like you guys are doing, uh, like unique things with your APIs. S
[00:36:39] Innovative Middleware and Routing
Andrew: o one that stood out to both of us was, uh, your routing configuration. The way you define middlewares is like both.
It's like the simplest I've ever seen. Uh, it's like immediately like recognizable what's happen happening and it's like, it's like what you said earlier where it's like, wait, why did we do it the other way? Like, this just seems like so simple and obvious, like the same thing goes for interceptors. So could you explain like where the inspiration for that API came from?
Peter: So it, so I, I looked at, at Remix, I think Remix Router. took the. at what they wow, nice. I love the way that they're calling the functions, et cetera. And then I wanted to, I wanted to focus really on the request response model. So in my mind I was like, a request hits this function. And it runs through a set of, of functions in an array step by step. So it begins with middle rare wear, we run each one of those and you can the context and then it figures out which route you're matched to. Uh, and then in that route you can also introduce something called the interrupter, uh, where you can say, okay, if this user in the context is not authenticated, then return aboard early, like interrupt the reflow and. Suggest that the person needs to log in and redirect them to the login page. Uh, so I wanted to give you both global control over the request then more fine grain control. the request. I wanted you to also have the ability to share those little, like interrupters throughout your code base.
So you could say, is this an admin user? Is this a authenticated user? And just reuse those everywhere. 'cause when you're actually reading the code and parsing it in your, with your eyes, you can see what's happening. You're like, ah, this is a authenticated route. Um. I think there's nothing worse than like something to production and you forget to the fact that this user needs to be authenticated, um, simply because you couldn't see it.
And that certainly you could still do that today, but, uh, it's much easier to understand where it's happening.
Justin: ~~Yeah. ~~
Peter: Yeah. So for the request response model is our, like beacon of truth, and we try to orientate ourselves around that understanding of how the web should be built.
Justin: I think there's like some, some other things that are interesting to point out here. the way that you define a Redwood SDK app. you have this define app function. It takes an array, functions at the top or middleware. You have this like route structure that's below that. The this is the shape of this looks a lot like how you define like v config with like define config. The, the important thing is to note is like that makes it very typable. A complaint that I hear about middleware all the time is that. You can't carry over types middleware to routes or whatever. It's like, you know, people are like, oh, magic is happening in middleware and I don't know what's going on. and there's all these like awkward type mechanisms and people put generics on the router itself and like do all these weird things. But the interesting thing is how you've actually architected this is you can do type inference from the middleware down to other things. I don't know if you're actively doing that now, but like the shape of it allows you to do that, which is like. An interesting point, uh, just to think about, like how that could be shaped in the future. yeah. I, I used remix a lot or React Router a lot and other projects, and I mean, I think they're working on middleware now, but historically they haven't had middleware and have had strong opinions about like not needing middleware.
And, I worked at Oxide computer company and they have a, um, HP like library that they built or a, uh. Request library that they built or whatever, that, uh, doesn't have middleware either they have like the same sort of opinions or like all these opinions about like middleware being this, thing can be that because it's like happening and you, like, it's not non-obvious when you're working on, you know, code for a route, like what could be happening.
But think it's like actually fundamentally important because there are just things that have to happen globally and also. I, I, the longer I work on web projects, the more that I. Deeply believed that you need to be really focused on the problem that you're solving in any one part of your code. And, and I think that you've done a good balance with like and the interceptors are like, sort of just like middleware per route.
Like this sort of model just like makes a lot of sense and, and like you said, it is like you can just glance at it and it kind of reads that's and think Like, I don't know. so yeah, big fan of the shape of that.
Peter: Thanks for saying that. Like I. I, I'd like to, I'd like to take credit for them and say just, you know, came up with it and it ended up being really amazing. Um, it almost feels like we discovered this by accident, like the router and the way that we define apps. It was just an iterative, iterative process and it just came out looking like that.
And we were like, whoa, this is really great. And we were all it, at, at, at what we had built. so I dunno where that came from exactly. You know, maybe just 20 years of experience the pain of building not really understanding exactly where things are flowing through the stack, and wanting to give people that fundamental understanding so that they can take that forward into their careers and build good software. Moving on. Um, and you know, like if you're focused on request response you're using sessions. Then you need middleware. So it was like, maybe the, maybe the, the fact that we're focusing on the browser made us make decisions that make sense. And those decisions make sense because for the browser.
That's your, know, that's your customer. And, and, and also like we, we really felt that we didn't wanna generate anything for TypeScript. though there's a little bit of stuff that's generated for, for CloudFlare, we will never introduce any kind of generated types. I think if your design time and your bold time are out of sync with one another, um, because to run a process to generate types. That's something that I'd love to avoid. I don't like doing that. I want, I want TypeScript to be class and not some kind of thing where I'm inventing syntax based on. Generation.
Andrew: So let's move on.
Peter: Yeah.
Andrew: Zero magic. No, no worries. Uh, so moving on to like the bigger visiony things that have to do with Redwood.
[00:43:28] The Vision for Personal Software
Andrew: Uh, we alluded it to it earlier, but uh, the big talking point is personal software and some software that you can build and own yourself. So what does that mean to you and like the vision going forward?
Peter: Yeah, I, know, I, I think we got called out on being somewhat nostalgic, and I'm give you a little bit of a personal story about myself. I'm a guy from South Africa that, you know, finished school in the year 2000. I in a rural community and. I was really into my computer and I saw this, I saw all my friends were in the United States.
Everything that interested was in the United States, that conversation because I lived too far away. Um, and when I think about personal software, I think about my journey in trying to become a better developer. Eventually getting to work with Tom Preston Warner, which was for me, a, a milestone in career. And. I wanna bring that to other people in the world. for me, I want to give people fundamentally good pieces of technology so that they can improve their communities, um, and, and build software for themselves that really scratches an itch that's not necessarily orientated around building a business.
I don't think there's anything wrong with building a business, you focus on that, uh, on that exclusively. The shape of the thing that you're building is very different. All of a sudden need, you need hypergrowth or VC money, and if you live in a place where that isn't accessible, you're not gonna build anything.
So I'm saying, Hey, your problems. You have, you have friends in a community build things that make their lives better, and that's it. You know, like, that's good enough. Maybe you get a career out of that, or maybe it grows. It blows up to be something huge, you never know. But unless you try, you're never gonna figure it out.
And. Alongside that, I think there's this massive group of people that are starting to build software. The, the vibe coders or the, the people picking up, uh, agents. And these are technical people that have a passion for something, but not necessarily the experience to pick the right parts. And I want to give them something that makes them feel like they're empowered, um, getting taken advantage of.
Like, I don't want you to learn some corporate Technology for the sake of, you know, uh, them being able to charge you $20 a month like that to me, I don't know, it just doesn't seem right, doesn't sit right with me anyway. I don't think there's anything wrong with making money. I love making money.
I want to make money from Redwood, SDK, but I think for now, I think software is gonna fundamentally change that we can scratch our niches. Yeah,
End rent.
Andrew: Yeah, no, I, I definitely resonate with this. I have a few websites that I've like carried along with me for like 10 years. Uh, if I've tried hard, I could have maybe made 'em into a business and like burnt some VC money, but like I. In the end, they were just like, for me, and I was the only user. And I'm like, I'm very excited to see what the future holds when that experience is like a generally accessible one.
'cause uh, it previously wasn't. And with the advent of AI tools, it very much is like, like your brother generating websites. Like I, I love that future and I, I just can't wait to see what happens and like all the weird software that comes out of it.
Peter: Awesome. And you know, the hard part, if the hard part isn't writing code, the hard part is hosting it. And that's why we, and that's why we did what we've done. know, the platform that CloudFlare provides gives you a good, solid basis to start on. Um. Yeah,
Justin: This is, uh, something related to this and. I think the message, you know, nostalgic may be, of course I'm a nineties kid, so, uh, it, it strikes home for me. But, there is this just notion that there are a lot of societal problems that software could help with just aren't VC shaped. Um,
Peter: them.
Justin: yeah, yeah, it like takes too much time, too much energy.
It's just not worth the engineering effort that goes into. You know, doing these like fundamentally, good for society things. And this is something I think about a lot. I'm, I've got a side project right now that working on to like, help people find lost animals, right? And it's like not a thing that's gonna make probably any money. and also it's like something that there are companies out there that are trying, that are solving this very, in a way that feels like kind of exploitive. And I, and I'm thinking, I've been thinking a lot over the years about like. What these shapes of opportunities are, and like, if they're even opportunities, how do you put software out for this?
So I, I don't know. I, I'm, I'm glad that y'all are thinking about it through this lens, because I think we need more out there in the world that's just like, here's a platform for like, building something that needs to be built, but it's like, maybe not the, you know, not, not the VC version of this needs to be built or like the expensive B2B SaaS version or whatever it may be.
Peter: Totally. And you know, I think there's, like, I, I've been trying to search for a term for the pain that I felt when I sometimes build software. There are things that I just fundamentally don't enjoy. and I procrastinate when I approach them. And I. AI has completely stripped that away from me. just, just lean in and I'm always in flow and I'm building cool stuff and it feels like I can do anything.
Um, and I think because of that, like it really enables us who are experts, we're not even learning. We can just spread, we can build so much stuff and really enjoy the experience. Um, yeah. Yeah. I'm, I'm really excited for the future of what, what, what we can achieve with software.
Andrew: Um, Justin, you wanna ask some of the long-term vision questions now?
Justin: Um, I will do, I'll do one, uh, like what does success look like, and then we can kind of maybe just do a wrap up question or we just wrap it up from there. Maybe.
Andrew: Yeah.
Justin: Um, I love this vision. I love the personal software vision. I'm a big fan of, which are building it in a lot of projects right now.
So, uh, I guess my question for you right now is you, you seem to have this like grander vision of like being able to.
[00:49:54] Empowering Developers with Redwood SDK
Justin: Give people a toolkit where they can buy or sell new components and build up these like small personal projects or, you know, small bus, like small software businesses. but like, what does the immediate future look like?
What is the next one to two years for Redwood? What are you really focused on? What do you really want to get shipped?
Peter: So, uh. The first thing we're gonna do is hit one 1.0. now sort positioned ourselves as uh, open beta. whilst we're trying to, wrap up some APIs. second thing that we're gonna do is release a, uh, the Marketplace resource code. Um, if in two years we have people actively on there, um, finding who love their code. Uh, and, and installing that in their own instances in CloudFlare, to me will feel like a personal success. Like if we, we can change the course of what people are building, um, into this, like more modular buy my source code kind of thing, I think that would be wonderful. Um, and you know, I, I love open source, but.
Uh, maintainers of open source traditionally don't get anything for the efforts that they put in. then, you know, you could probably just upload your code to our store for free anyway. Um, but I'd love for people to earn some money through do, through doing what they're doing. Um, and you know, like there's, there's some prolific, uh, developers on NPM Cinder. I, I, I'm probably not saying his name correctly. I think he probably has, like all the packages on MPMI, use at least 10 of them.
Andrew: Yeah.
Peter: and I know that he works as a, that's his full-time gig I'd love for people to be able to do that through Redwood SDK to find a place where they're actively writing software as their, as their job and just scratching their eng own niches and selling it. And, know, GitHub stars. So that is one of our, I'm being facetious, but please star our project it helps us, uh, prove that we are, we have people engaged with what we're doing. yeah, I want more stars than anyone I.
Andrew: Well, if you can make a dent in, uh, funding software developers like that, that would, that would be huge. Like literally just the other day, like I've been working on a side project. To that is like a react component for window splitting. I'd probably put like two months of my off time into it. Uh, and like I'm just giving it away for free.
It's, and it's, 'cause there's not really any easy way for me to not do that. Uh, so if we could foster an environment where that's an easier thing to do, uh, I would love to see it.
Peter: Yeah, and you know, it's, it's like, it's like you wrote this thing, you found it useful, perhaps some other people do. So just put it on there and see what
you come to our store with the intention of actually buying something, or, or you're like, I'm busy building something right now, I need a forum, or I need a, this component that does this thing. It's for sale. You're gonna buy it. gonna be like, all right. Also, I mean, it's not like a thousand dollars or whatever, maybe it's just $5, you know, like anything really. Uh, but you've exchanged that, that value. You said, thank you. You did something great for me. this. gonna put it into my code.
I own the code as well. redistribute but I own the code and, um, I can modify it for my own needs. think that feels good. the platform that we on is the same thing. to 12,000 different services. I could also just on see if it actually works. so you can validate if that's doing the thing that you it to do.
Andrew: Yeah, there, there, there isn't really that like look like. Cheap to like medium price point for like selling stuff. Like if you wanna do charts in React and you wanna buy a library for that, that's when it cost you like $2,000 per developer per year. It's like crazy that it's like either you give away your work for literally $0 or it's $2,000 ahead.
Peter: You know, of the things that I always find so and like frustrating is like when you find one of these charting libraries, they'd be like, this is enterprise. This is an enterprise charting library. And you're like, what does that mean? Like, that mean the documentation is worse? Or like, yeah. about the price
obviously.
Andrew: Yeah.
[00:54:36] The Future of Software Development
Andrew: Well, with that, that wraps it up for our questions. Thanks for coming on. This was a, just a very interesting, uh, journey into the, both the history of redwood and how we got here, react server components, and all this personal computing stuff. So many, so many different things to be excited about.
Uh, so thanks for coming on and talking about it.
Peter: Thank you so I'm, I'm here for the personal software revolution. and the reason why I'm calling it personal software is because I think of the. of personal computing where people had to convince you a computer in your home. kind of, I'm trying to convince you to write your own software, like put your own software our store and you know, scratch your own edge. That's the time.
Justin: Well, yeah. Thanks Peter for coming on and I'm excited to see this future and hopefully participate in it. This is, uh, yeah, it's, it's good calls, I'm here for it.
Peter: Thanks, Andrew. Appreciate it. Cool. I.