RedwoodJS: The Full-Stack React App Framework of Your Dreams

I know what you're thinking. I want to make a web app. So I'm going to need React. I'm going to need Prisma on the backend to talk to a database. I'm going to need Apollo to talk from the frontend to the backend.

I'm going to need Jest so I can write some tests. I'm going to need Storybook so I can design code and test my components in isolation. I'm going to need Webpack to glue this whole thing together. And I'm going to need Babel so I can compile, transpile ES6 down to ES5.

That's the web app, but I'm going to need to figure out how to deploy this thing. Maybe it could go to Netlify. They're really into Jamstack. Maybe it could go to Vercel. They've got a cool Triangle logo. What about render? Maybe then I could use containers and get long-running requests and GraphQL subscriptions. Or maybe I need the full power of AWS. I haven't decided yet.

In any case, I'm going to need some kind of authentication so I could use Auth0 for that. I'm not going to write my own. Gotta go further than that, though. I also need authorization. So I'm going to need some role-based access controls. And what about logging? I'm going to need really good logging send out to the provider of my choice.

I'm going to have to code-split this thing so the browser doesn't get too much code at any one time. I'm going to need OG tags, so this thing will unfurl on Twitter and Facebook. Gotta have pre-rendering probably in order to do that. And I'm going to need accessibility right out of the box. This thing works in screen readers.

All right. Let's do this thing. That's not really how it works, is it? It's more like this.

All right. Google my old friend, create react app. Okay, there you are. What's this? There we go. Launch. CX. Create react app. All right. What am I to call this thing? Gloobnox? That works. All right, we'll let that do its thing for a while. Let's learn how to use Prisma. Okay, Prisma, here we go. Nope. Not that one. Nope. Not that one either. Aha! Found you. Yep. Here we go.

Prisma docs. Quick start. All right. In this page you will learn how to send queries to a, okay, great. All right. This is going to take the rest of my life. But despair not, because I'm here today to tell you about Redwood JS, the full stack React app framework of your dreams.

Now, I know what you're wondering. Who is this bozo telling me what to do? Well, I'm Tom Preston Werner. You can find me online, at MoJombo on Twitter and GitHub. In the past I've created such companies as GitHub and Chatterbug, best place to learn a foreign language. I have also very active in open source. I created Jekyll. I wrote the semver, the semantic versioning specification, TOML, the configuration language used by a variety of packages, and Gravatar, the avatars that follow you around.

Now, getting back to this screen, remember all these technologies? These technologies are awesome, but you don't necessarily want to think about all of them. In fact, Apollo is great. But really, when I write an application, I want to worry about GraphQL and not really the intricacies of Apollo. And I also really don't want to worry about Webpack or Babel at all. In fact, I want to focus my attention on writing JavaScript or TypeScript. That's what I'm here for. I'm a programmer. Let me write code. That's what I do.

And so a Redwood application is going to be broken down into two sides. Very simple. A very simple model to think about. On the web side, you have your React application. This is where you think about your testing with Jest and your storybook. Those happen locally but conceptually they are really part of the web side of this. And then on the API side, you have an implementation of a GraphQL API that uses Prisma and a bunch of JavaScript or TypeScript to create your services, your business logic that is going to talk to your database and do what you need it to do. In between you've got GraphQL that talks back and forth. And GraphQL is how you make queries and also how you specify the queries and mutations that are going to happen. But enough chit-chat, let's see some code. I have here on the right opened GitHub.com slash Redwood JS slash example to do. This is a simple to do application written in Redwood that I thought I'd run you through a few things, and show off how Redwood works and how it thinks about the world. So I've cloned this down to my local machine. I've run Yarn, you can see the instructions here. And I've initialized the database. So it's all set up, ready to go. So the first thing that I'm going to do is run Yarn Redwood dev to spin up the web server. This is going to spin up both sides that I talked about before, both the web side and the API side, the front end and the back end, link them together, and fire up a new browser window with my to do list. So I'll show you how it works. I can say I need to order some milk, and some cheese, and some eggs. And I can toggle these things on and off. This is talking to the back end via GraphQL. You can see here in the logs, the posts to the GraphQL back end. So how does that work? Well, in the editor over here, you'll see the web folder and the API folder. This is a monorepo structure. So these are each separate packages within a single Git repository. So let's start where everything starts, which is with the routes.

So in the routes file here, you can see that we have a router. And within it, we have a route for the homepage and a route for a not found page. This is essentially the 404. So this is our homepage. And in Redwood, we have another directory for pages. It's very easy to find things, very organized, the directory structure.

So this is the homepage. This app is using styling components, which you'll see here. And it's just standard React. So this should look very familiar if you know React. So here we have a wrapper, we have the title, to-do list, and then we have a to-do list cell.

Now, Redwood has a really special concept called cells, and cells are a way to declaratively do your GraphQL data fetching. So let's go look at that. To-doListCell is in source components, to-doListCell. So source components, to-doListCell. And here's the file. And how this works is you simply export a certain set of variables from here, constants, including the query. So you start with your GraphQL query, you just type it out here as a GraphQL query or you could have a mutation in here as well, which you can actually see here. And then you have different states and you just export these states as components. You have a loading state and a success state. You can also define a failure state and an empty state. Right here, I've just done a loading. It very simply says loading. And a success state. And so what this does is really simplify and focus you on what you're building. So in this instance, when this query completes, whatever the query name is, the GraphQL query that you're doing, in this case, to-dos, that will be sent in as a variable, as a parameter into the success component. And then within that, you can do your work. So this is doing some optimistic updating which you don't have to worry about too much for Apollo. But right here, you can see that it's just taking the to-dos and mapping over them and creating to-do items which represent each of these items here. And that's what cells are. So really, it's just a simple way to think about your data fetching, so you don't have to do a lot of conditional logic. It really organizes the code around that.

Now, when you get to the back end, to the GraphQL side, let's see what that looks like. So here's the query to-dos. I'm going to look in the API side here. I'm going to look in source, GraphQL, and to-dos. Now these we call services. So you break up your Redwood application into different services. This app is very simple. It only has one service, this to-dos service. A larger application, you might break it down into different services for the different responsibilities that your application has. So here we see an SDL file that is defined in a JavaScript file. And here's the SDL. So if you've written GraphQL before, then this should look very familiar. This is straight out-of-the-box standard SDL, the schema definition language. And here we're defining a to-do object and queries and mutations. And the nice thing is, each service can have one of these files, and they can all be separate, and Redwood will do the hard work of stitching them together and presenting them to the world. So let's look for what we were talking about. To dos is going to return an array of to-do items, which are defined here. And when you're normally writing Apollo, you have to think about writing your resolvers, and there's a specific way that you do that, and they all end up in the same file, and it can feel very messy.

It feels like a lot of boilerplate. So we've eliminated all of that in Redwood and said, well, let's just match things up by name. And so, if you come into these services directory and look at services, to-do's, to-dos.js, what you're going to see here is a constant, to-dos, this is the same name as the GraphQL query, being exported, and Redwood is smart enough to match that up and say, this is the implementation. This is the resolver for that GraphQL call. And in it, we're going to use Prisma, which we just import here. DB represents the Prisma database. And now we can do any of our Prisma calls on that. In this case, we're just doing a find many. So a really fun way that we can explore that as you may be already used to is with a GraphQL playground, and Redwood, of course, ships with one of those, and that's going to be at localhost 8911. And we can try this out. So I already have loaded up the same query that we find in to do lists cells, just the to do list query ID, body status. And if we run that, then we can see that we get back exactly what we expect, milk, cheese, eggs, and everything is as it should be. And really, that's all the code that it takes to do the front end to the back end.

So all right, that's cool. You say, what about doing this from scratch? Having it all there right now is one thing, but what if we want to do something from scratch? Well, let's give that a try. I'm going to close all of these. And I'm going to switch over here. And what should we implement? I think it would be fun to have a page that just showed me the count of to dos. Maybe something else needs that for some reason. It's a simple thing to implement. So we have the ability to generate certain things in Redwood. So I'm going to run Redwood, sorry, Yarn, Redwood generate or just G for short, page, and I'm going to call it the count page. I'm going to run that. And what I'm going to see here now in my routes file is a new route has been generated slash count, takes that from what I've typed in here. And it has created a count page for me. So let's go look at that count page. It's also creating stories file for storybook. This is integrated out of the box. And a test. This is the just test. So we're beautifully integrating all of these different elements. Right now we can go look at this in slash count. And here we go. This is just the the generated pages is what it looks like. If we make any changes in here, then they will be immediately reflected over on the website. So you can you can go back and forth very, very simply and do this.

Okay, very cool. Now we need to get some data from the back end. So let's switch over to the API side now. And we're going to modify our SDL file to create a new GraphQL query. And we're going to call it to do's count. And it's going to return an integer always an integer. I have a Redwood extension installed in VS Code here. And it does some nice things. So here you'll see that it can tell me that this service is actually not implemented. I don't have an implementation for this specific query. And so this is just a very nice way. Because we do some things automatically for you, we want to also help you see when some of those automatic things aren't going to work properly.

So this isn't implemented. Well, let's go implement it. That's in services to do's JS, we're going to create something called to do's count. We'll do that right here. Export const to dos count. That is going to be a function. And it's going to just be db.to do.count. Okay, well, let's see if that worked. We should be able to run it and see if it worked. And here we go. All right, there we go. See, I added two lines of code and I created all of my GraphQL infrastructure that's necessary in order to get the back end working. So there we go. In a new GraphQL query, defined, ready to return some data and be consumed by the front end on this count page.

Well, we're going to need a cell. We're doing data fetching. So we need a cell. So let's create a cell. Yarn, Redwood, generate, cell, todos.count. We'll let that run. And we're going to find this in components, todos.count, cell right here. Now it's generated this and it's guessed what I'm going to write as a GraphQL query, but it's a little bit wrong. Let's make it correct. It's just going to be todos.count. Like that. The loading state is fine. The empty state, this is what I was talking about before. These are all predefined. We just change these as we like an error failure state. And the success state is just going to by default just do a JSON stringify on whatever comes out of here, which is just going to be an integer. And that's fine for now. We like that. And now we're going to use this in the count page. So let's see in here. Why don't we say todos.count is going to be the todos.count cell. And then we need to import this. We're not using that anymore. So import todos.count cell from source components, todos.count cell.

And if we come back here before we save this, then there we go. And that's really, that's really it. We did all of that in a couple of minutes. I could, if I wasn't talking so much, I could have done that a lot faster even, but that's front to back, all the way on the React side, to the GraphQL, all the way to the backside, Prisma, to the database, the whole thing with just a few lines of code, a few generator commands, and that's really how easy Redwood tries to make everything that you do.

Now I mentioned before that we have Storybook integration as well, so I'd like to show that off real quick. In order to get the server, the storybook server running, I'm gonna run yarn Redwood storybook. And that'll take a few seconds to spin up. And when it's done, it's gonna launch this page, and you'll see here we have the storybook stories for the things that I've generated. We have the count page, which is generating, and check this out. It actually has some data for the count that's coming back, but that's interesting. 42, where did that come from? And why does it say ID there? That's a little bit weird.

Well, the reason that that's happening is that it's pulling it from here. So the count page is that whole page, is pulling from this count cell. And one of the things that we do for you, if you were paying attention over here when we created this, and I came into this directory, is you'll see this mock file. And this mock file is gonna make it really easy for you to see your cells in storybook, because mocking out your data fetching in storybook is one of the real challenges to getting storybook working really nicely with your application. Again, Redwood tries to make it really easy for you. And so, we have the concept of mocking your data fetching. And in this case, we've just said, we think that todos count is going to return an object with an ID. You might remember that that was what we guessed you were going to do. But it's very easy to come in here and just say, Oh, it's actually just returning a number. And save that. And now, you'll see that the success state of this updates. And indeed, the page itself will update. So, all of these components can use these mocks, the cells. And that means that when you have a page or you have a cell or component that has a cell in it, anytime you have one of those, if you use it in your storybook, it's cool. It's just going to pull this mock data and it's going to include that. So, it's still very easy to visualize your components and work with them without the hassle of trying to think about how you're going to get that data mocked out in there. And again, you can very easily now work on the loading states of these things. So, to dos count cell has these various states. I might want my loading state to just say, just wait. I can save that. And now, instead of trying to be in my app and clicking refresh and being like, oh, what did it, what, does it look right? Oh, I see it. It's there for like a, you know, a hundred milliseconds or something, even less. That's kind of a pain. And I can go to my inspector and I can make my page really slow. And that's annoying. But that's why we have storybook. Now, I can come in here and I can stare at it for as long as I want. And I can just, I can make it work. Or the empty state, what does that look like? What happens when I get an error? If I want to make an error happen in my application, I have to go into my implementation, probably, and add some kind of a syntax error so that it's going to throw some kind of error. Now don't screw around with that. That's why we have storybook and Redwood is all about making the entire thing, the entire application development process end to end as smooth as it can possibly be with as little amount of work, as little amount of boilerplate as we can possibly make it for you. We have spent so many hours reducing boilerplate and doing integrations of these products. Integrating Jest, integrating storybook, removing Webpack. You'll notice that in here, you really don't see Webpack at all. You don't see Babel at all. Of course, we have some config files for you in case you need to dig into them, but you never have to touch them, really. If you're just doing normal things, this is not a part of your job anymore. Let the framework do the heavy lifting for you so that you can focus on your business logic. Well, what else can Redwood do for you? Well, I'd like to show you something that we released recently.

That is pre-render, the ability to take any of your pages and specify that they be built at build time, that they'd be rendered at build time and then statically shipped. So how's that going to work? Well, let's say you have a splash page, some kind of a marketing page that really doesn't have a lot of dynamic content and you just want to render it at build time and make it available. So let's do that. Let's create a page that is really just static. So I can run Yarn redwoodgeneratepage, I'll just call it splash, and we'll get that splash page and let's go to it here so that we can see it. And let's find it, web source, pages, splash page, and in here we're going to make this we're going to make this pretty simple. Let's just go with this content but what I want to show you is how the hydration is going to work when we do this and how easy we make that as well. Let's make this a button instead and give it an on click that is just going to be a function that runs an alert, hi. And we'll just call that splash because that's what it's already called. And we'll see now that we've got an errand to get rid of that guy. OK, so now when I press this, it says hi. OK, that's expected. This is all dynamic. If you turn JavaScript off in this mode, this is the fully dynamic single page application. I can turn it off. I have a little JavaScript turn off button right here. I'm going to click it and you'll see no more page, obviously, because React is mounting the entire thing. All the HTML comes from JavaScript and React and that's not always what we want for SEO reasons, for performance reasons. There are a lot of reasons why we might want to get this stuff generated at build time. So we turn it back on and you'll see it. So how do you do that in Redwood? How do I tell Redwood to take this page and pre-render it at build time? Well, let me show you. You might expect that it's easy and you will be right. In fact, it's one word easy. All I do is come to my routes file. I find the route that I want to pre-render and I just add pre-render onto it and that's it. I just did I, I'm done. That's the only thing that I need to do. You're like, hmm. Can that really be true? Can it be that easy? Well, let's, let's try it. Can it be that easy? Well, let's, let's find out. So, uh, I have this, uh, specified now. And what that means is during the build, it's going to pay attention to that and build a static file for that. Um, and so I'm going to show you how to run a build and then you can inspect it. And in, in Redwood, you just run red yarn, Redwood build, and that's going to, um, do all the steps necessary to, to actually deploy this. This is really what happens during the deploy process. It goes through the website. It goes to the API side. Um, and then it has a pre-rendering step. And during the pre-rendering step, it's going to look for any routes that has been specified to be pre-rendered and it's going to render them. So let's look at the web disc directory. That's where the, this, the website of this ends up. And you can see that there's the index, there's the favicon. There's the normal stuff there's static files. This is where the JavaScript lives. This is where the CSS lives. It's all chunked up webpack, right? We did all that for you. All the code splitting and everything happens via that mechanism. And then we have a splash dot HTML page, and we can look at that and we can see that this is the text that we see here. My default route is et cetera. And here's the link to me with the button splash.

But look at this, button, splash button, right? There is no JavaScript. In this page, because it's static, there's going to be no JavaScript. The expectation is that there is no JavaScript at this point. But what we want to be able to do is hydrate that page after the HTML is loaded and and you have the content on your browser and then layer on top of it using reacts hydration, the functionality.

So let's see if we can make that work. Well, I can show you how this works by going into the web dist directory. And I'm just going to run serve, which is just web server. It's going to spin that up. It's going to copy the URL to my clipboard. And it's going to send me into my app. And unsurprisingly, the home page doesn't work because it is a a full app and there's no back end. And the error here is I can't find my GraphQL. OK, that we expect that. But what if we go to the splash page? Ah, we have our content. Indeed, we do have our content. And now I want to show you that it's real by turning JavaScript off. So I just did that. JavaScript is currently off. So when I press this button, nothing happens because there is no JavaScript on this page. But what if I turn JavaScript back on? You'll see that it reloaded. I'll prove it reloaded. And now boom, it's still dynamic because it loaded the HTML and then it loaded react and layered that on. And that's that's a beautiful that's a beautiful thing. This is how you can get a statically generated pre rendered page that can still be dynamic, but you get all the benefits of SEO because this is what Google is getting right here. Google is going to see this. So if you have SEO concerns on marketing pages, then you want to pre render that. It's one word, one word in your ads file.

Remember this ridiculous screen that I assembled before, Redwood has a solution for every single one of these things. All of the stuff in the application authentication providers from Auth0 to Netlify. To many others, a bunch of deploy targets, including Netlify and Vercell and render and the ability to deploy your API side to AWS. We have so much more in the works to make your life easy. The whole point of Redwood is that we do the beautiful integration for you so that you can focus on your product and what makes your business valuable. If you want some stickers, you can get those on the website. We'll ship them to you free anywhere in the world. I'm really happy you joined me today. And I hope you come and join our community and find this stuff really useful. Completely open source, MIT licensed, free for you to use. We do this to try to make your life easier. Thanks for watching.

So you are asking everyone, what kind of infrastructure do you deploy your web apps on? And it seems that Virtualized won. It's the most voted. And after that, it's followed by Container, which is render, begin, fargate, Cloud Run. And on the third place is JAMstack. I have to admit that in my opinion, I'm using Virtualized. Just because I can get my hands on the virtual machine. But what are your thoughts about those votes? I think this is really interesting also because there isn't one clear winner. There isn't one that really super dominates the rest. And I think that's super interesting.

So an interesting fact about Redwood, when I started working on it, it was really envisioned to be a full stack web application framework for the Jamstack. But as we've been working on it, we've found that exactly these results are kind of the case of how people are thinking and operating. And so we need to adjust our our homepage and our marketing now. But really, the goal is to target all of these equally and kind of follow you where you want to go. And depending on your application and what your use cases are, you might choose different ones for different reasons. Like you might choose to go on to Netlify for the ease of deployment. And it's just so simple. But you might need more control. You might need certain things around containerized, a containerized approach or just virtualize straight on easy to so that you have total control. And Redwood is happy living in all of them. There is no there's no vendor lock in. We're not specific to any given vendor. And we try to make it really easy and have built in deployments for a lot of these. Where you just say Redwood, yarn Redwood deploy, you give it a target and we'll do most of the rest for you. You'll have to make some choices, but we try to make that Redwood easy.

Oh, great. Is if we are going to talk more like more than two minutes having this slide, oh, I think it's going to be evenly distributed for the first three places. So, yeah, it's pretty obvious. It seems that I see three, I see two or like visualized one. But as you said, it's it's morphing based on your needs, right? Yeah, let's see. What are the questions? Let me grab a couple of them from we had we had lots of questions for you, that's for sure. The first one is coming from Dermo Hamad. He's saying, what what's the difference, the main difference between Redwood and BlitzJS? Yeah, that's an excellent question. I think Redwood and Blitz both live in a similar space, we're both trying to be full stack web application frameworks that are on top of JavaScript typescript. I think one of the big differences you'll see is that Blitz is based on Next. They've kind of used that as a starting point to build the additional functionality off of where Redwood we have not really built on something that is quite as sophisticated as Next. So for instance, we do our own routings. We have a custom routing solution that allows you to put all your routes into one file. Some of these things are inspired from what I really loved about rails. And that was a big one for me, was the simplicity of kind of the routing layer and how that allowed you to trace your code trivially. And it also gives us a lot more flexibility around how we want to approach the situation in general. I think Blitz has sensed this a little bit. They've had to fork Next in order to do some of the things that they want to do. So I guess our choices of what our baseline kind of build point was, is a little bit different. And that expresses in different ways. In some ways, it's really beneficial for Blitz to have such a solid foundation to work on and you get all of the things that Next already has out of the box, that we've had to really think about building from scratch. But to me, I really like that. I like having a more blank slate to work from. I don't like to be pinned in by some of these choices. Another big thing is that we use a GraphQL layer very specifically to talk from the front end to the back end. And I know a lot of people were wondering about that.

And one of the biggest reasons that we do that is because we've envisioned Redwood as a multi-client framework so that it becomes more than just a web app framework. It becomes a cross-client framework. So oftentimes when you start working on a new product, you're going to start with a web app that's pretty normal that you're going to have one. And we love React for that on the front end. And then later on, you'll decide, oh, I need a I need a mobile application. And at that point, what usually happens with frameworks like Rails or if you were using Blitz, this may happen. Then you say, OK, well, I need my client to talk to my back end. So now I guess I'll reimplement some kind of an API so that I can talk from my mobile app to my back end. And now you're duplicating work that you've done before. And so what we said is, let's just start with the assumption that you're going to be multi-client or eventually want to be multi-client and create the abstraction between the front and the back end and use a protocol that is really efficient, very well known. There's clients for everything that you would ever want to interface with so that when you decide that you want to do a command line interface for your project, guess what? Your application is already just a GraphQL API on the back end. And so there is no additional work to do. It's already completely engineered from the very beginning to serve a client that ends up being sort of abstracted. But you still have full control over that. You're building the GraphQL API yourself. So you have both the flexibility of GraphQL in its best parts, but also the flexibility to use it across multiple clients. So that's really the crux of why we chose GraphQL for that. So those are two of the big differences. And, of course, there are many. Just our approach to lots of things are slightly different. It's just different. We both think differently about things. And I encourage you to explore both to see which one might serve your use case better.

It's, yeah, it's really fantastic. I mean, you took inspiration from Ruby on Rails, which also have generators, your Redwood JS also have generators. You have services like the layer that communicates with with things and the backend. It's fantastic.

I have a question. Since you also touch the Next.js part, the question from Vlad F is how is Redwood handling SSR? Since Next.js is handling SSR, how Redwood JS is handling SSR? Yeah, I think Next has really made itself a real winner in this area. So super relevant question. These are questions that we've had to kind of re-imagine from a Redwood perspective, thinking about what we really try to do is think from first principles. What do you need as an application developer? And so we're starting to really think about these problems from what is the problem that you have and how can Redwood solve them for you in the most elegant way possible? In the talk, I showed our pre-render support. So that's one portion of what SSR might do for you. You have this problem where you need to have content generated that you don't wanna generate it at build time, but you'd like to have it cached and served. And you might do that for various reasons. One of those reasons might be because you need to have OG tags and support for that. And so this is where pre-render. Pre-render is just the first of many features that fall into a category we call Redwood at scale. Because all of these things, if you think about them, all of these strategies, things like SSR are really about caching. They're really about performance at scale. And that almost always boils down to some form of caching. And so when we think about caching in Redwood, pre-render is the first implementation that we've started along that path, where we say, what do people often need? They need the ability to statically generate marketing pages, because there's no reason to do them dynamically. But it would also be nice if they could be rehydrated so that any small bits of interactivity on the page will still function. And that's what pre-render is. And as you saw, it was a single word in order to enable that across multiple different deployment platforms. And so that's really what we want to do for the rest of it. So we will eventually have solutions for something that looks a bit more like SSR or you saw Netlify today just came out with their solution for this that maintains atomicity around deploys and can make it a lot more easy to reason about. So we'll leverage those things on these different platforms and make them really easy to engage with hopefully as little work as possible in the meantime. So our approaches will be different I think than Next. They'll look a little bit different. But they're going to be really specifically aimed at solving problems that web application developers have in the deployment and scaling part of application development.

Great. Imagine Wagons is wondering how about TypeScript. Yes so we do have TypeScript support so you can tell Redwood to generate you a TypeScript template instead of a JavaScript template. It's not quite done. You could so well, I mean, you can do it. You can have it provide you a TypeScript version. And it's funny in order to do that right now, we're still working on the interface for this. In order to do it right now, you actually pass a dash dash no dash JavaScript flag, which might seem a little bit weird. But it's because the template actually is already in TypeScript. And we compile it down to JavaScript for the JavaScript version. But we don't have full TypeScript typing across the entire application yet. And so we'll smooth that out. 1.0 is gonna ship with full TypeScript support in the way that you expect.