A JS framework for startups: Redwood goes 1.0

Hello, and welcome to another episode of JS Party. I’m Kball, I am your host today, and I am so excited for this episode, where I get to bring back one of our favorite guests, Tom Preston-Werner. Tom, how are you doing?

I’m doing well. Thanks for having me back. It’s been probably a year since I was on last.

I was looking back at when the last one was, and it was March 2020. Believe it or not. So it has been–

Oh, two years. That’s right, because that was right after we released the first version of Redwood. That’s right.

Yup. So two years, and that was right as times were real crazy around.

Oh, yeah. It was an interesting time for everyone, I think, as the pandemic was getting started. And so that’s interesting… Redwood really has been this pandemic project.

Yeah, totally. So we’re excited to have you back. Redwood 1.0 released, and I want to dive very deep into what it is. But I think because it has been so long, maybe it’s worth taking some time to kind of explain for folks who may be unfamiliar with Redwood, what it is.

Absolutely. So Redwood is a JavaScript and Typescript full-stack framework optimized for startups, or for anyone who’s building a side project that you might want to turn into a startup. What we really want to do is make your life easier as someone building a web application, or other types of applications too, mobile clients. Now, we don’t make that as easy as we will someday, but because of the architecture of Redwood - and I’ll get into the architecture and how we use GraphQL - we want you to live in a multi-client world. And so all of these things we’ve thought about from a Redwood perspective, to make your journey, building a project, growing a team, making it all maintainable, trying to make that as easy as possible, as smooth as possible, as integrated as possible.

[00:04:09.10] Redwood really is a play of integrating all of the best tools and then adding some really great code on top of that to glue them all together and simplify some of the common processes you have. But to really deliver a full-stack JavaScript or Typescript experience for building something that might be or already is the size of a startup.

Interesting. So when we first talked, the pitch was, okay, Redwood is going to be the Ruby on Rails for the JavaScript world, and you highlight that a little bit here. It’s like all these different pieces integrated and pooled together. Can you sort of flesh out a little bit more what that looks like? Because we’re not very familiar with that in JavaScript.

Yeah. Well, Redwood really started as kind of a technical experiment to see if I could build a full stack framework for the JAMStack. And that used to be our tagline, was full stack for the JAMStack. Because of what Netlify made possible– and I’m on the Netlify board. I’ve invested in all the early rounds of Netlify, and have known the founders since forever… And when Netlify started to make it really easy to package up lambda functions and get those deployed along with your more traditional JAMStacky, like your static HTML, or if you have a React app that you’re going to deliver via the CDN - I thought that was a really interesting model and could be the base of a more modern kind of architecture for full-stack applications. If you had a React application that you want to deliver via the CDN and you have your business logic which you can deploy onto lambda functions, and then you have a database somewhere - and that was that kind of the unknown, part of it - two years ago, when we were working on this it’s like, “How do you deal with this? There’s not a lot of good serverless databases.” Now there are. So that part of it is actually mostly solved, and we made that work.

So you end up deploying an implementation of a GraphQL API that you write in JavaScript or Typescript, onto a lambda, but you deploy the entire thing to a single lambda, which has certain characteristics. Lambdas are not perfect for everything. And so this architecture works and makes that possible. And we have a lot of people using that still today, this serverless deployment option for Redwood. But what we also realized was that’s not going to be suitable for everyone. So there are certain performance characteristics that you might not like. The cold start times are still longer than we’d like them to be. You will eventually max out how much code you can put into a single lambda function.

And so we started experimenting with other deploy targets, and so now Redwood is not specific to serverless at all; you have an option. You can still deploy serverlessly, if that’s what fits your needs, but you can also deploy to traditional serverful providers, things like Amazon. We have a deployment option that we call Bare Metal now, where you deploy in a way that looks very similar to how you did it with Rails and Capistrano, where you’re SSHing into an EC2 instance and getting it set up in that way. And it’s super-fast. It’s really amazing. You have all the flexibility you want around that. Or you can go somewhere in between, right? You can deploy to Vercel, as well as Netlify. You can deploy direct to EC2… But you can go in between with services like Render, where it’s more of a containerized style approach. And so Redwood works across all of these.

And so that was one thing that brought us away from the initial sort of idea for Redwood. And so we started thinking, “Well, what is the differentiator for Redwood?” Why would someone choose Redwood over something like NextJS, which is obviously the most popular player in the React universe for building a site, and for good reason. It’s really a great technology. So why would you choose Redwood over some of the alternatives? And what I started to think about was how much we integrate and how much we do for you out of the box and who’s going to need that, because some of these things make the framework more complicated.

[00:08:19.17] Like, if you look at Next, Next is really pretty simple. There’s not a lot to it. It has a small surface area. It doesn’t try to be full-stack. It gives you hooks to do database calls and other things that you want to do from a server side perspective, but it’s not trying to be opinionated in the way that I wanted to build a framework that was more like Rails, to give people a lot more out of the box, make a lot more decisions for you out of the box. And so Redwood integrates React on the front side, and it uses GraphQL to communicate from the front end web SPA to the back end, which is a GraphQL implementation using Apollo server. And then you use Prisma as an ORM to talk from your GraphQL API to your database, and that’s all in your business logic.

And then on top of that, we also integrate Storybook and Jest for testing, and we have a bunch of authentication providers that you can install with a single command line invocation, as well as different deploy targets. And all of this and a bunch more - logging is included, security by default for your GraphQL API; a really great way to build your GraphQL API using what we call Services… And then on the front end, declarative data fetching using what we call Cells - all of these different things, we’re packaging up and integrating. And to me, that looked like what you need to build a startup; something that is larger than a weekend sort of hack that you might do to experiment with some idea. That’s where Next, I think, shines so well, in just the ease with which you can get something up and running.

With Redwood, you have more complexity out of the gate, because you’ve got– I mean, GraphQL alone and the strict separation that that gives you from the front end to the back end is more complicated, and so it makes it more difficult perhaps to hack something together in an hour. But if you’re building something for the long term, a little bit of that upfront complexity that you have to deal with is going to give you great dividends and maintainability in the long run, as well as helping people– once you grow a team, you have specialized people developers. Some people are doing front end, some people are doing back end. You’ve got all these different roles. And having that kind of separation of concerns of what the different parts of the framework are doing - to me, in my experience as building large pieces of software and large companies, that is what becomes extremely valuable and maintains your velocity in the long run.

And so that is what made us start to say, “Well, Redwood is optimized for startups. It’s the app framework for startups”, because that then is something that someone can say, “Oh, I’m building a startup. I want a piece of technology that’s going to get me further, faster and do more for me, and deal with all of this stuff that I don’t want to have to do, so that I can focus on the things that make my business different.” And so that’s why we’ve really started to talk more as Redwood being for startups.

I feel like there’s a number of companies and frameworks that have started in that space, because startups tend to be kind of early adopters, willing to– if it takes work off my plate, that lets me get to a business faster and MVP faster, I’m happy to do it. So you talked some about, it’s putting a little bit more structure in place. What other types of optimizations or changes have you made since shifting focus to look at startups as a target audience? How does that guide decision-making or what are the other angles that that brings forward?

[00:11:54.09] I think I’ve talked about a lot of them. I mean, a lot of it, it doesn’t even look like technology. It looks like community. It looks like partnerships with the different companies that we work with, so the different authentication providers like Auth0, or Clerk or Magic Links. There’s like seven or eight others. Or the deployment providers, or the logging providers, or the database providers - all of these are companies that we have strong relationships with, and that allows us to go deeper into helping people with those technologies or helping people to make choices between those different options that you might have. And a lot of what we do is spend time with people in the community. So we have a startup club, that if you are a startup, whether you’ve raised money or not is not really the point. It’s more like you’re building this thing, it looks like a startup… If it looks like a startup and it feels like a startup to you, then to us, we’ll invite you into the Redwood startup club where we are able to listen to people’s needs as they’re building and growing their products. But not only that, really talk through the problems that every startup has around trying to figure out how to hire people, or how to determine if you have product-market fit or how to choose some of these options, deployment providers, like what’s going to work for your use cases, or how to raise money. So I have relationships with a lot of venture capitalists, a lot of VC firms. I do angel investing myself, and others in the group have done startups before.

And so we really use this as a channel to help you build a startup outside of just strictly the technology. And so that also is part of the play, is that if you want to build with Redwood, then not only do you get a great piece of technology, a framework to help you do that more quickly and scale and build multiple front end clients with as you need, but you get advice around how to build a startup and a peer group that is trying to build a startup as well. So it goes well beyond what most frameworks are trying to do from a community perspective in helping you get done what you want to get done.

Yeah, that’s really interesting. So you’re almost envisioning this now as it’s a tiny piece of this more startup ecosystem play that you’re making.

Yeah. I mean, these are my great loves. One of them is building tooling for developers. Another one that I’ve been doing for the last five or six years is investing in startups. And so I realized that Redwood, the technology can be this really amazing combination with the investing that I do and the advising of startups. I spent a lot of time talking to founders, and as an entrepreneur, I really enjoy giving back in that way, of helping people succeed in trying new things. And so what we say for Redwood as our mission is we want to help more startups explore more territory more quickly. And that’s both via the technology, the framework, as well as the community and helping you accomplish those explorations.

I’d love to dig in a little bit more to this 1.0 release and kind of talk about, explicitly, what does Redwood look like today? What is that technology piece? What is it that– you mentioned some areas around choices that you’re making versus others where you kind of make it more flexible for folks, and maybe you have recommendations. So what’s in the box, in the 1.0 release? And where does Redwood shine today, and where is there maybe still some room to grow or some challenges?

Yeah. So the reason that the 1.0 release took two years from the initial 0.1 release is because we wanted it to really feel like a competent way to get a full application out there, with all of the things that if you’re building some kind of a SaaS project, you are a startup, that you could use Redwood and really get there with what’s in 1.0. So it has all of the fundamental pieces that we think are necessary. So I listed them off before, but it’s essentially a React front end and a whole web side. We call it a web side, an API side, because we imagine that eventually in Redwood, there will be a mobile side, like a React native side, or command line interface side, or a public GraphQL side, where you take some of your GraphQL API and you’re able to document and release it and give people guarantees about how long that lasts and how it’ll evolve over time.

But all of those things, we want to make possible, and so that’s why it’s the website. So we have a full website and a way to do routing on the front end that we think is novel and interesting, a way to do declarative data fetching that we call Cells. All of that’s been in there and all of that was really important to 1.0.

We built in and spent a lot of time making sure that the back end, the GraphQL API, was secure by default. And so this is something in the GraphQL world that is non-trivial. If you just start writing a GraphQL API with Apollo Server, that’s really the bare minimum that you need to get it done, and it’s a little painful if you haven’t done this before, figuring out how to do it. And even things that seem like they should be trivial, like separating out your GraphQL API into multiple files, instead of having one giant resolver file, are non-trivial to do. And so we’ve done a lot of that integration work for you, to make it a really beautiful experience, putting a GraphQL API together.

So a lot of it was around polishing that, and doing things like authentication. So how do you integrate with your authentication provider, of which you have many different choices, and make that not turn your GraphQL API code into a horrible mess? And so making sure that that was really streamlined and that you can put permissions on your GraphQL queries and mutations, so all the different things you want to do; each one, you might have different requirements for, and say, “Okay, well, if you’re going to want to list some resource, then maybe you can be anyone. So don’t do any auth all. But if you want to delete something - well, now you need to be an admin.” How do you do that in your GraphQL implementation? There’s a million different ways that you could do it. All of them are choices that you have to make. All of them are going to be annoying to some extent, because authentication is always annoying. So how can you reduce that to the minimum annoyance possible? And so what we’ve come up with for Redwood is to use GraphQL declarations to do that.

[00:20:49.11] So in your SDL file, in your GraphQL schema definition language file, your SDL file, where you’re saying what your types are and your queries and mutations, next to a query or a mutation, you can just put a declaration for your auth. You can say, “Skip auth”, if you don’t want any, or you can say, “Use auth”, which is kind of the built-in authentication mechanism that then gets hooked into whatever authentication provider you’ve chosen. And so there’s not really any work that you have to do there to use that. Then it’ll just say, “Okay, you need to be authenticated as a user”, or you can say– because we have built-in role-based access control in Redwood, then you can say, “Oh, I want only admin role people to be able to do this mutation”, for instance.

So that’s all baked into the framework, things that you don’t have to figure out, technologies that you don’t have to evaluate, and they feel very natural and streamlined. And so that was a big thing that took quite a while to nail down. And we went through a couple of different iterations of how that authentication and access control might work within the framework.

So it’s all of those things and really developer experience is paramount to us. And so we’ve had to make some explorations and some mistakes around what things look like to bring things to the level of simplicity that we demand for the framework itself. Even though it is more complex, architecturally perhaps, than some of the alternatives, it’s still important that that complexity does not prevent you from getting things done, and then it really ends up being a boon to your productivity over the long run.

Well, and as you highlight, it’s doing complex things… Like, integrating auth and RBAC, role-based access control - that’s a complex thing. That complexity is gonna live somewhere. I have this thesis that complexity is conserved, right? It’s either exposed to the user, or it’s baked into something somewhere. So you have baked that into the framework, where that complexity is there, but I as a user of my framework don’t really have to worry about it.

Right. But it’s also trying to not use too much magic. There’s always a balance here; it’s like, “Okay, you’re going to do all this stuff for me, but what if I want to make different choices?”

Yeah.

“What if I don’t want to do authentication in the way that you make really easy, because my requirements are a little different?” And so we’ve tried to be really conscious of that as well. And so for the authentication provider, all of these things are written essentially as in sort of a plugin style, where you could write your own. And the way that you do it is to implement an API around authentication. So they’ve all been– in order to allow you to choose any of them, there is a layer that has been abstracted that is all of the things that you need to do from an authentication perspective. And each of the providers then implements that API, and you can roll your own custom authentication in exactly the same manner, and do whatever you want in that regard.

So that kind of feeds into a question I had. So one of the things for me that happened as Rails - and I keep using that as a metaphor, because I was familiar with that process early on, and I loved a lot of it. As that project evolved, it went from being opinions that were hard to change out, to opinions or conventions that were much easier to swap around, if you needed. Where in Redwood is it easy to sub things in? Or maybe it sounds like for some of them it’s hard. Where is it still hard? If I wanted to, for example, swap out Prisma or something like that, is that something I can do?

[00:24:22.22] Yeah. So that’s probably the best example. So the things that are easy, swapping out or changing authentication providers or deploy targets are both super easy, super-duper easy. Swapping out some of the core– let’s say the main three core bits right now to Redwood would be React, GraphQL, and Prisma, let’s say. Those are kind of the three assumptions that we make. If you want to change one of those, then you’re going to end up doing a lot of work on your own.

So it’s GraphQL. So you can build whatever front end client you want. If you like Vue or you like Svelte, or you like whatever, just writing anything you want as long, as you can consume GraphQL, then you can build anything you want. This is the multi-client aspect that I’ve talked about where now you can have a mobile client, you can have a command line client, you have a kiosk at a mall, you could have an app in your Tesla. Whatever it happens to be, GraphQL is going to make it possible for you to do that, and it’s going to make it possible for you to not have to reimplement your backend to do it. This was a lesson that I learned several times, which is, if you start building your application with Rails, for instance, and you have a traditional Rails frontend, then you do your backend in a certain way that feeds into your views and whatever; your life is good. But then you’re like, “I want a native mobile client, or a desktop application”, and now you’re like, “Oh, crap, I guess I have to build REST, or I can try to tweak Rail’s backend stuff so that it’s also RESTful”, which is like the dream of what Rails can do, but never really quite the reality, to be able to reuse your sort of–

It’s a very leaky abstraction. [laughs]

Right. It doesn’t match real well, right? So then you’re like, “Okay, but I’m going to build my mobile client in React, so I’m going to use React Native, and that really matches well with GraphQL… So I guess I’ll now write a GraphQL implementation alongside my Rails backend.” And now you’ve written two backends, and nobody wants to write two backends… Because I’ve done this several times and it’s a nightmare.

Yeah, I have as well, and it is never good. You end up with these fun database as API-type things where you’re having to then make sure that you’ve got all the same access control and other things working… And yeah, it’s a nightmare.

Right, you just always have two things you have to think about. And then different teams are working on the different aspects, and now they have to talk about like, “Oh, if you’re going to change that thing in the user interface, then the GraphQL API needs to reflect that, too.” And there’s two places. So part of the fundamental reason to architect Redwood this way is the idea that you’ll only implement your backend once, and it will be as GraphQL… Which - some people don’t like GraphQL. If you don’t like GraphQL, then maybe Redwood’s not for you. But if you believe that having the ability to create any client you want and consume GraphQL, that that would be advantageous because you intend to have multiple clients, then I think Redwood can be a very good fit for that.

You’ve done a few more things than just having it be React, because you’ve implemented Cells in this declarative rendering or declarative data fetch. And we had talked– two years ago when we spoke, you talked about trying to get in the flow of data fetch, so you can solve the waterfall problem, which is something that I know Remix has also done a bunch of stuff around, and that’s a big area that folks are focused. I guess I should check first… Did that end up happening? Is that part of what you get in Redwood 1.0, is you’re able to solve the waterfall?

We have not tackled that yet.

Okay.

That is a big question, like, “Where does your data fetching happen?” Now, with Cells, we are able to get into the flow of that. And so this is something that’ll be a research project now that we have 1.0 out. So we couldn’t do everything for 1.0. We had to sort of cut aggressively in order to even get a 1.0 out the door. And so we were not able to get some of those optimizations in, but I’m really excited to do some of those research projects to try to make some of those things possible.

[00:28:20.07] Well, then this is maybe not as relevant there, but I was wondering, is that separation of having the declarative model, because there are so many nice things that you can get out of that - is that something that you could separate from the React-based implementation? So if somebody is swapping in another framework, they can get some more of the batteries?

Yes. So you don’t have to use Cells. And we have some people that don’t use our data fetching. We have one guy that uses Relay. He’s like a Relay expert. And so he’s like, “I’m going to use Relay instead, because that’s what I know.” And so he doesn’t use Cells, and he doesn’t get some of the nice things because of that, but he likes working in this other kind of way. And that’s totally possible to do, because we’re trying not to add so much magic that it’s impossible to untangle some of these things.

And so Cells are really not that complicated. It’s a higher order component that we’ve implemented, and it does that data fetching for you. And we then have some things in Storybook and in testing that integrate really well with Cells to be able to do your mocking, and whatnot.

So there are other advantageous things in the Redwood world that you’ll also be giving up if you’re not going to use Cells. You’ll have to do some of that work yourself to replace some of those things, like how do you mock data now for your tests and for Storybook if you want to use them ? That’s now on you. That’s not the golden pass. You’re going to have to do more work there.

But yeah, so you don’t have to use Cells if you don’t want to. Or you can make GraphQL directly using whatever GraphQL client you want from the frontend, at any time. And some people do that for things like– there’s a React table implementation that kind of handles its own data fetching, and you can totally do that because, again, it’s just GraphQL, and you can make that work. So you don’t have to use that.

But one of the things that’s unique about Redwood is the routing mechanism. So we have built our own router, and it allows you to put all your routes into a single file, essentially, which I really liked from the Rails world. So this is different than sort of the nested, split-up React router kind of paradigm, but it allows us to do code splitting in a really clean way, as well as just showing you the entire structure of your application in a single place, which to me is valuable, especially from someone who comes in new to your project and wants to figure out how your application works or how to find a specific piece of code that’s running on a certain page. Being able to have a single route file that you can look at and reason about is really valuable from that perspective.

So there’s a variety of things that we’ve done in that regard. That’s one of them. But there’s so many more optimizations and things that we have in the plan, that we haven’t been able to do yet, because of the breadth of integration that we really wanted for 1.0. That is what took precedence.

I want to fully answer your question from before about what are the parts that might be easy to swap out. So GraphQL - we actually do have someone who uses tRPC instead of GraphQL, and that’s a large chunk of work that one would have to do in order to make that work. But indeed, it is possible to swap out a transport. If you wanted to do so, it can be done. I wouldn’t recommend it. I think that’s a bit beyond the scope of what a normal Redwood user would want to do.

And then on the backend, Prisma… You don’t have to use Prisma, but again, you’re going to miss out on the integrations. So generators are– the Redwood generators… So if you want to scaffold and create all the CRUD operations that go from front end to backend and the interfaces, all the GraphQL stuff and all of the simple web admin interface and the tests that we use and the generators are all written against Prisma. They expect you to use Prisma. So you wouldn’t get some of that stuff. But you could certainly use whatever database you want.

[00:32:11.23] So if you want to use– we recently talked to EdgeDB, which is a new database provider, serverless. It sees the database more as an object graph, but it has a proper schema with it. Super-interesting. So we’ve talked to them and they’re like, “Well, what would it take to allow you to use that?” Because then you wouldn’t be using Prisma, you’d be using their kind of client that they’ve written, special for that. And I think it’s not too bad. Actually, we could abstract out the generators to be able to, without too much trouble, even fix up the generators so that you could use the generators, and now it would just write against EdgeDB instead of against Prisma.

Yeah, kind of creating the same layer that you have for your auth, where there’s an API they write against and you have an adapter and it works.

Exactly. You just keep abstracting more and more up the chain, and then eventually, nobody has any idea how–

It travels all the way down.

…the codebase works, because everything’s like three levels of abstraction between it and reality. But I mean, this is how a project becomes more flexible, and that’s on us to manage the complexity of the framework codebase itself. But because it’s JavaScript - you can fetch from anywhere. If you want to read from a Redis somewhere or– it’s all JavaScript. You can– whatever. If you can do TCP/IP, then you can do your data fetching from your backend, read from a data source, however you want. You just won’t get kind of the magic goodies that Redwood makes possible.

I want to maybe dig in… So if somebody is trying to decide, “Hey, there’s so many cool frameworks out here. There’s Next”, we’ve had a couple conversations recently about Remix, there’s Redwood… Walk me through what the decision tree would look like. When would I and when would I not use Redwood?

Well, first of all, do you like the technologies in general? Do you like React? Do you like GraphQL? Do you like Prisma? If you like all of those things, then Redwood becomes a pretty easy decision; especially GraphQL, because Redwood’s really the only one of these that builds in GraphQL and makes it really easy to actually implement your GraphQL API in a way that’s way easier than you’ve ever done before.

So I’d say if that’s what you like, if you think that you’re going to have multiple frontend clients right out the gate - you’re going to have a website, you’re going to have a mobile client; if you know already that you’re going to have those two things, then Redwood also becomes really attractive, because you’re saying, “Okay, well, I’m going to think about my application as a GraphQL API. I’m going to have multiple different frontends for it, so I only have to implement my backend once.”

So that becomes very attractive if you envision a future in which you have multiple clients… Because everyone else is going to hide the API from you right now, or it’s going to be some proprietary thing, or– it’s not exposed in a way that is first-class for consumption by multiple different kinds of clients in the way that GraphQL is like, “I am an API. Call me from anything.”

Yeah.

So I’d say that’s one of the biggest differentiators for Redwood from a technology perspective, is the GraphQL part of it. And the level of integration that we have is another one. Nobody else tries to integrate as much as we do. So again, if you like the technologies that we’ve chosen, if you’re like, “You know what, Storybook would be great, because either I want to have this great resource for keeping track of all of my React components and use it as a design reference for frontend developers to be able to see what we do”, or my favorite thing, which is to use Storybook as a way to do isolated development of your components, so that instead of trying to work on your components in your actual application, and then trying to get the database in the state that allows you to see the states that you want of that component, instead you just work directly in Storybook to build your React components, and now you can feed it any data that you want, and say, “Oh, I want this to be true, and I want this string to be this.” And now it can look like anything that you want, and you don’t have to fiddle with your application and be constantly refreshing to get it to where you want it to be; or you’re like putting random data into the database to get it. It’s such a pain.

[00:36:19.01] Or like looking at loader states, right? It’s like, we’ve all been there where we’re like, “Alright, I’m just going to keep hitting refresh, and I’m going to open Inspector and set it to slow 3G so I can see my spinner for three-quarters of a second. I’m just going to do that over and over until I get my spinner”, right? With Storybook, you’re just like, you could look at it all day long. Just open it up, there it is. That’s the state.

So if you like Storybook, if you like to have some nice things around testing done for you… So when you get sophisticated, so if you’re a startup and you really take testing seriously, you’re going to want to do end-to-end testing, which we make easy, you’re going to do– or you want to be able to mock out your data fetching, and with GraphQL and the help that we provide you, we make mocking out and providing that mock data to your cells on the front end really easy with both your tests and in Storybook. So you can even, in Storybook, see your data fetching cells and the different states that they’ll provide - the loading, success, failure, empty… All those states just become different things you can click on in Storybook and they’re mocked out, and we make that really easy to do.

Or with testing, we’ve created what we call scenarios, which are a way to set up your database for a specific scenario of like - let’s say you have a user and they need to have three of some object, and that’s now your user with three object scenario… Which might be different from your user that’s totally brand new, and they’ve never added anything, and you want to be able to test against that; or you have a user that has a credit card set up and they’ve interacted with these four different users… All of those, we make really easy to set up those as different scenarios and test against them in your testing.

So if you like to do rigorous testing and you want that to not be a huge, painful thing that you have to manage yourself and add all of these mocking and scenario database setup types of things, then you might choose Redwood, because those things are all available out of the box, as well as logging that we provide for you. We integrate Pino for logging, and you can choose then to set that up against different log ingestion scenarios, depending on where you’re deploying to.

So those are all reasons that you might choose Redwood from a technology perspective. And in addition to that, then you might choose Redwood because of the community that comes along with it, and the help that we can give you around managing, thinking about and being successful with your startup from the human side of it, which is often even the more difficult side, right? So if you like more with your technology than just, “Here’s an open source repository. Good luck”, if you want to have a community of people that are building and going through the same struggle as you and you like that idea, then that might be a reason that you would choose Redwood as well.

One last question on this domain - how is performance? I’m thinking things like server-side rendering, data fetch, I was thinking about bundle size… All these different aspects.

Yeah. I mean, they’re not going to be any different than your traditional SPA. So right now the website of Redwood is a fairly traditional single-page application architecture, and so there will be some performance implications because of that that we’re all used to. Now, we have the ability for you to be able to pre-render pages right now, and then they’ll hydrate on the website, on the browser, after you do that. And these are all things that are fairly common today.

This is the one thing– so let’s say you’re looking for reasons to not choose Redwood; one of them might be, “I need more server-side rendering capabilities”, which something like Next is really great at. The kinds of things that Next can do from a SSR perspective are really great.

[00:40:15.17] We actually have a lot of startups now that are using Next as essentially a client for the GraphQL API. So they need to have HTML delivered, with OG tags, for instance, or whatever the reason is to be delivering something from an SSR perspective, they’ll use Next and have it call via GraphQL to the back end to fetch the data, and that ends up being a fairly common pattern. Now that we have 1.0 out the door, I would love to get some more of those SSR capabilities into Redwood itself, to be able to, on a per-route basis, essentially specify what characteristics you want, whether you want it to be pre-rendered… Which you can currently do, and you just say, “Pre-renderer in the route.” You just add pre-renderer to it and now we’ll pre-render in build time, and that’ll be delivered out to whatever your deployment provider is in the right kind of way, for that to be delivered as HTML and then rehydrated. But I’d love you to be able to say, “I want this to be server-rendered as HTML”, and delivered in that capacity in a similar kind of way.

Now, there’s some challenges and weirdnesses around that because of GraphQL, where it’s like, okay, now the server is going to execute the page and it has to talk GraphQL to itself. That’s potentially a little weird, so then I was thinking, “Well, maybe you can drop GraphQL and it can talk to the services directly.” Because in Redwood, the way that you implement your GraphQL API is really in a very Javascripty way. So if you’ve ever done this before via resolvers, in like Apollo server or something, you’re essentially providing it a bunch of functions that are the resolvers, but you have to pass at arguments that are in a kind of a weird way. There’s no way that you can really reuse any of that logic in other places, because you’re all just stuffed into these resolvers. And so with Redwood, we’ve added a level of abstraction on top of that, so that when you’re implementing your resolvers, they look like just regular JavaScript calls, and they receive an object of arguments, and then the other stuff that you might pass into the resolvers as additional arguments.

But the reason that this is nice is that you can now call those resolver functions from other places in the code. So let’s say you have a GraphQL mutation to add– let’s say you’re writing a blog engine, and you have something that’s going to add a blog post. That’s something that you might want to be able to trigger from somewhere else in the codebase. If you’ve got that stuffed as just this function that’s being passed or implemented in a resolver, it’s like, how do you reuse that? So code reuse becomes really challenging in kind of the simplest way that you would write your GraphQL resolvers.

But in Redwood, it’s really just how things are named. So if you name a function a certain way that matches what it is in the SDL, then we’ll match those two things up, and that’s done automatically for you, but the signature of it is still done in a way that it makes it easy to call from other places in the backend. So you could have some other function be calling your ad a blog post function the way that you would normally in JavaScript, but because it’s named a certain way, then it gets picked up by the thing that exposes the GraphQL.

Yeah, that’s really interesting. So I think Next and Remix, and these folks often– their server-side rendering is still the client, right? They’re still rendering a client and expecting to have an API. And then they do have endpoints you can call for the API, but I think that’s a network call, and it’s probably a local thing rather. But what I’m hearing here is you could potentially kind of sub out the GraphQL client to have a server-side rendering client that just calls directly into those functions. So it’s just running the same process in JavaScript, you don’t have that little network call or anything?

[00:44:03.04] Yeah. It’s more like– I mean, in Next, if you’re doing the server-side where you get the server props, essentially, it’s going to execute that on the server directly and it’s going to do whatever that you have in there; usually, you’re fetching data from a database, or something. In the same way, we could have Redwood allow you to do– on the webpage if you’re using cells, then you’re going to provide it a GraphQL query, and it’s going to do the network call, and then you’re going to get the data back, and that’s going to go into your success component. Is there a way that we can, depending on the GraphQL call– like, these are things that we’re thinking about right now. Is there a way to cut out the GraphQL query in that regard, and have you specify it more as just a function call? So maybe you know that it’s going to be done server-side, and so you’re not even using GraphQL, you’re just allowed to call the services directly, because you know that you’re in that execution environment. That’s the hard part, right? I mean, there are things about SPAs that are annoying, especially around hydration, where you have to now be sure that your page can execute in both a browser and a node environment, which can be fraught. If you don’t know that that’s going to happen, then you’re like, “I’m going to use this library.” And you’re like, “Oh, you can’t use that library on the browser.”

Right.

That’s not a thing. And you’re like, “Oh, how was I supposed to know that?” So there are other things that we’re thinking about around how can you tell people in advance that this is going to happen, that something is going to have to be able to execute in two different environments, and warn them if there’s going to be a problem in doing that. So these are things.

And then at the same time though, I get interested about other approaches to frontend, like Qwik; it’s a new sort of experimental frontend that is trying to deliver as little JavaScript as possible. So in that way, it’s a little bit like Svelte. But it does hydration, but it does it by resuming. So it’s not building the whole page on the server and then delivering that and then basically rebuilding the whole page in React on the browser, and then repainting with basically the same thing. It’s really resuming. So it’s not having to rebuild on the client. It’s just resuming the execution essentially where it left off on the server. So you can get kind of these advantages of the server and client interaction without having to waste cycles in doing that.

So that’s really early still, but I like the architecture of Redwood because it allows us to explore these things. So like maybe in a year we’re like, “You know what? React is dead, and now Qwik is where it’s at.” We don’t have to replace any of the backend stuff. The backend stuff in Redwood is all great. And you don’t even have to use the frontend, right? If you don’t like the React web side, throw it away and build your thing in Vue, or Svelte or whatever you want. Or maybe you only have a native mobile client or a native desktop client; don’t use the frontend stuff that we have in Redwood at all, and use it for the API, because it is amazing at that. If you just use Redwood to be a GraphQL API implementation, that’s a great place to be, too.

So I’d love to get a sense… We talked a little bit in the end here of like some of the things that are there, but what is the vision for Redwood 2.0, or 1.3, or wherever we’re going? And I’m kind of curious to explore along three dimensions. So one is how are you organizing the project yourself? Because I think you’re doing some unique things there in terms of how you’re funding and things like that. What do you see as the future in that community aspect you’ve talked about? Maybe those are the same thing or maybe they’re subtly different. And then technically, what are the– you know, we’ve talked about all sorts of dimensions we could go, but what are the next 1, 2, 3, and then what’s the pie-in-the-sky long-term vision? But maybe let’s start on the organization.

Yeah. So one thing that’s maybe a little interesting about Redwood, organizationally, is we have a fairly large core team. It’s around 20 people right now. That’s because we really like to invite in people from all kinds of backgrounds and experiences, and especially skill level. So we’ve had people on the core team that were essentially just out of a boot camp, and they come in and they’re able to do some things with the code, but they’ll participate maybe more, at first, in the community aspect or in the outreach aspect, where they’re writing blog posts or they’re doing podcasts. And that’s been really valuable for us, to have that more beginner perspective, for people to come in and say, “This is confusing. How does this work?”

That kind of feedback helps us really improve the documentation, to make sure the tutorial is really rock solid… We’ve spent tons of time on the Redwood tutorial. It is one of my favorite things about Redwood, is how much time we’ve spent making sure the tutorial is solid and that it’s tested and it works and it’s really enjoyable. And we’ve produced videos around it in case you just want to watch it. We’ve spent tons and tons of time on the tutorial. And those things are great because of the different experiences of the core team members.

[00:52:21.07] And so people come and go out of the core team, and we like that, because we like giving people opportunities. I mean, a big part of why I do this at all is because I love building tools and I love giving people opportunities. And so anyone who comes in that wants to level up, that wants to contribute and be a part of this, and if I can help them succeed in that way and land a job, which a bunch of people that have come into the core team that were more junior on their path were able to land jobs because of their involvement in Redwood on the core team. And that gives me a great deal of satisfaction.

And so the core team is large and sort of ever-evolving. I mean, I would love to have a 50-person core team someday; and we’re able to do that because we have really great leaders that are able to organize that. Mostly, I speak not of myself necessarily, but of David Price, one of the co-creators, who spends most of his time engaging with the community of contributors, the startups, and really deeply creates these relationships that then turn into people that come on to the core team, people that can be successful in a way that is more organized than you’ll generally see in an open source project.

So organizationally, that’s kind of how we are. We have a core – within the core, there’s maybe a deeper core of people that are involved every day, and people that I pay to work on the framework. And then we have a larger core of people beyond that. And then we have our larger set of overall contributors, but we spend a lot of time trying to make it easy to contribute to Redwood. So we’ve done a ton of work to make it possible to get the framework up and running and alongside a test project, so that you can make changes to the framework and then see that in an example application, which is not a small feat in the world of JavaScript because of the way that NPM works, or Yarn. The way that that works makes it really difficult to get a dependency local, so that you can make changes to the dependency and have it reflected in your actual application. That is a monumental nightmare. We’ve gone through several iterations of making that possible, and it’s really smooth now. And especially with Gitpod. Now you can go on there and you can spin up a workspace in Gitpod and be working on the framework itself in a matter of 30 seconds, and you’re working alongside a test project and the whole thing is set up. And you can also test pull requests this way. You can spin up any of the pull requests on Redwood, in Gitpod, and immediately be testing it in a live environment on Gitpod.

So we’ve spent just a huge amount of effort making it as easy as possible for contributors to come in and get started. And David runs a series that he used to do every two to three weeks where he’d spend an hour with people who expressed interest in becoming contributors, going through this whole process so that people would be set up to be able to work on the framework itself. So we’ve spent more time and effort than I think most in working on the contributors’ community and making it possible for people to get started… Because it’s not easy; coming into a large complex framework, and contributing to it is non-trivial, shall we say.

Totally. Yeah, I love to hear about that. Community-wise, what are you working on there? So that’s sort of the community of the framework, but you’ve also talked about this community of startups. Is that something that is actively evolving? Do you have a vision for where that’s going?

[00:55:57.06] Yeah. So we have - let’s say, there’s about 30 startups that we know of that are building with Redwood right now. And we try to track as many as we can to get a sense of, is this angle of optimizing for startups - is that working? Are they out there? Are people choosing Redwood and building with it? We want to know. This is helpful for us to build the future of Redwood. So we know of 30– I think, it’s 31 at the moment; 31 startups that are building actual real startups with Redwood. Many of those are funded. The last time we got the numbers, it was about 19 million of funding that Redwood-based startups had raised. This was right before the 1.0, so that was a month ago. So that’s probably increased from there.

But it’s working, people are building with Redwood, and they come in and the feedback is generally very positive. They’re very happy with Redwood and their choice in doing that. And a lot of it is because of the technology, especially the multi-client, the GraphQL stuff is really important to a lot of people and how easy we make that side of it. But then the community as well, and how open we are to people being involved. And when people make a choice of a framework like this for their company, they want to know that they are going to be heard, that they can come in and they can fix things that are broken if there’s something that’s affecting them, that the core team is going to be responsive to say, “Oh, you have a need for your company, for your business. We’re willing to accept your pull requests. We’re willing to engage you and help you in getting those things fixed.” That ends up being really important to people when they’re making a choice for the long-term of business choice; something that’s going to affect the success of their business. So that’s been really important.

And so we’re continuously growing the Redwood startup club. We also have a community member, Keith, who works on the Maker hHour, so which is kind of a– that’s a bit more of an open forum for anyone who’s tinkering with Redwood or building anything with Redwood, not necessarily they’ve committed to doing a startup and they’re growing a team or whatever. That’s the startup club. The Maker’s Hour is more just like, yeah, you’re doing whatever you’re doing with Redwood and you want to talk to other people about it, or share what you’re doing to be motivated, and so there’s a group of people that often come to the Maker’s Hour to come share that.

There’s also a Spanish language version of that, that we have a community member leading now, which is pretty awesome to see… And then we also do office hours. So some of the core team members will get together every week and do office hours on Discord, so that anyone can come in with any other questions and just have someone available from the core team to be able to answer those. So we have a Discord where we have an active chat community where people come in, and we’ll do some events and things in there. That’s a great place to just meet other Redwood developers, ask simple questions, and get help, or get pointed to the discourse forum software, where we really have this ever-growing knowledge base that is the better place for asking questions and getting answers that may be a bit more complicated than you might ask in the chat and on Discord.

That we chose because we wanted it to be indexed across time. And so this is where a lot of people land when they’re searching for things about Redwood, like “I have this question, how do I implement this thing?”, or “What service should I choose for this other thing?” or like “How do I–” whatever; then you’ll often end up in the forum, and that’s on purpose. We wanted that to be this long-term growing resource that’s indexed, it’s searchable. So all of these things are part of the community that we’ve assembled, and that’s all going to plan.

[00:59:48.29] It’s hard to grow a community. It’s in open source. It’s especially hard from a diversity perspective, and we work really hard to try to increase the diversity of who we see in our community, but it is still overwhelmingly white and male, which we’re always trying to counterbalance with outreach to other communities. And this maybe segues me into the Redwood startup fund, which I can talk about, which is a purposeful effort to increase the diversity of who we see, especially as startup founders.

So the Redwood startup fund I announced when we launched the 1.0. This is a $1 million investment fund that I’ll run alongside the angel investing that I do, where I intend to write $25,000 to $50,000 cheques to startups that are using Redwood in their stack, to encourage people to build with Redwood, obviously, but to also fill out the latter part of the startup journey that we can offer directly. Up until then, we could offer you technology to build with. We could offer you a community and help to think about and strategize about and connect you with people in the startup and investment community, but we couldn’t give you actual money, directly. That was not part of what we could really offer.

Now with the startup fund, for those startups that we really believe in that we think can go the farthest, we have money available directly to fund. So 25K to 50K cheques, really early. I’m hoping this can be super early-stage funding, maybe before you’ve even incorporated your thing, or even written much code around it. And I’d like to prioritize a more diverse set of people that are building. So more women founders, more black founders, other minoritized groups in the software development community that want to come in and do that, but may otherwise not have the option to do that, because of whatever constraints that they have, or just to have someone who believes in you, that has some money to where you can get started and try out an idea. This money is intended to increase the diversity of the community directly through how we prioritize who gets that money.

And the other side of that is, I’d like to prioritize startups that are working on climate-related things with the software that they’re building. This investment is run through Preston-Werner Ventures, which is the entity that I use for angel investing. We also do a lot of work around climate. We have a team of 10 people at Preston-Werner Ventures where we do grants around climate, as well as political work to try to move the needle on climate change. This is a primary focus of what we do with the Preston-Werner Ventures effort that my wife and I run.

And so I’m trying to dovetail all of these things together, sort of combine the open source work that I love to do with the angel investing that I love to do, with the climate work that I think we have to do, and try to pull them all together into a tighter bundle of things. And so that’s the startup fund. So that’s another part of community-building and trying to purposefully evolve the community into what I think is a healthy direction.

Awesome. Well, let’s close talking a little bit about the technical future. What do you see coming next in the framework itself? What are the focus areas for, say, the next six months, and then where– if you haven’t already covered them, are there any things that you see as like, “Ooh, we’ve got to get there someday”?

Yeah, there’s lots. So one of the biggest things on my mind is some kind of SSR type of a solution, whether that be something that we can bake into Redwood itself, and make it really easy on a per-route basis… That’s a little complicated because of the architecture of Redwood, the GraphQL choices that we’ve made. Or is it just making it possible to use NextJS as another web side and then making whatever integrations we need there to allow you to use NextJS in a more official capacity. Just some story around you have certain needs around SSR because of what you’re doing, and making that possible. So we’ll be doing a lot of thinking about that in the near term.

We’ve been going over this with the startups that we’ve been talking to, and then in the community in general, just trying to think about what are the next biggest things for the roadmap? Because I want to really be driven by the people using Redwood and their needs. Especially if you’ve chosen Redwood and we’ve made this promise to you that we’re going to help you build your startup, then it’s incumbent on us to keep building the things that you, as your company evolves and you’re using Redwood, that you’re going to need as time goes on. So a lot of those things end up looking like scale; like, what do you need at scale? So that’s why we think about SSR. But other types of caching as well.

[01:04:33.20] So it’s possible to do GraphQL caching, GraphQL layer caching with Redwood right now. There’s some how-to’s on the website in the docs about how you can hook that up to a Redis, for instance, to do GraphQL caching, in a very similar way to Graph CDN, the company that is doing GraphQL caching. Graph CDN is great. If you want to have more control over it, then you can actually do GraphQL layer caching with Redwood itself via a plugin to Yoga, which is the GraphQL framework that we use now. We started with Apollo Server, and now we’re using stuff from the Guild, who are amazing and we worked very closely with over there to be the GraphQL web server. So there’s things around that. Improvements to testing, adding in additional sides… A lot of people want a native mobile side, and they’re waiting for that, for us to say, “Alright, here’s the React Native side, and here’s how it integrates, and here’s how we’re going to make it improve the DX of building a React Native client alongside that.” That is one of the most requested things right now.

Things we talked about before, like waterfall, like how can you improve the overall– like if you have a page that’s going to be doing multiple different GraphQL calls that don’t need to wait for each other, but they’re nested, how can we gather those up and do them for you simultaneously? So that’s a bit of research that I’d love to do in that regard. I mean, there’s a lot of just bug fixes and kind of small improvements to all the different aspects, where it’s like, “Oh, there there’s some missing bit of how you do your testing. How do we fill that in?” So a lot of the work will just be working through the backlog of issues and pull requests that are outstanding, now that we have some time to stand back and say, “Alright, now that the push for 1.0 is over, where are we going to go from there?”

So we’re really in the phase of nailing down what the roadmap for the next three to six months looks like right now, now that we can take a breath from getting 1.0 out the door and really talk to the startups and people using it. So I can’t paint for you a really solid picture of exactly what those choices are going to be, but that’s a flavor of some of them. And there’s just so much room to improve still in the world of JavaScript frameworks. When we started two years ago, there were others that started around that same time. So now we start to see a lot more people thinking about and doing integrations around this. It’s really nice to see, finally, this coalescing of some of these ideas happen in the community.

[01:07:17.05] Yeah. It feels like the pace of innovation at the UI framework level of React versus Vue versus Svelte has slowed down, and now there’s all this interesting innovation happening at the application layer, or application framework layer, of like how do you package these things together into a useful application?

Right. Exactly. Which is great, right? That saves people time.

Awesome. Well, is there anything else you’d like to leave JS Party listeners with about Redwood?

I’ll just say, if you find any of this stuff interesting, come visit the website, redwoodjs.com, do the tutorial… So if there’s one thing that I would like you to have as a takeaway from this is if you are intrigued, go do the tutorial on the website. You’re going to love it. It goes through all of the primary aspects of what makes Redwood different and special, and it’s a great introduction to the various technologies that we have in there.

There’s a really great section on testing that is– if you haven’t done a lot of testing before and you’re like, “Man, I should really be doing testing”, go do the Redwood JS tutorial or read the testing documentation. It’s written by Rob Cameron, who’s the same person on the core team, co-creator that wrote the tutorial, and he’s just a master of communicating these complex technical ideas. And it’s just a great intro to testing JavaScript with Jest, the testing documentation on the Redwood documentation site.

So come do the tutorial. That’s the number one thing. And once you do that, then you’ll know whether Redwood is for you or not. If you find it awesome, then great, come join the community, come pop in Discord and say hello or ask any questions that you have. We would love for you to be a part of the community. And I get a lot of satisfaction out of building stuff. It’s my favorite thing. Creating something from nothing is the thing that drives me the most, besides just learning things in general. And it’s just so pleasurable for me to build things that other people are using and enjoying, and taking people’s feedback and continuing to improve and exploring new ideas and helping people explore the territory of whatever is interesting to them. So we’d love to have you involved in the community. Please come by, do the tutorial.

Awesome. And we will, of course, include links to the tutorial and the Discord and all the things mentioned today in our show notes. This has been fun. Thank you so much, Tom, for joining me today, and I’m looking forward to, I guess, myself going and doing the tutorial. I took some looks early on when we talked, but then haven’t had time to touch recently. So I will dig into that and look forward to seeing what comes next.

Alright. And you can even watch the tutorial with the videos. You don’t even have to do the tutorial yourself if you don’t want to. So that’s a great way to do it as well. Thanks so much for having me. This was really great.