Rock Solid React and GraphQL Apps for People in a Hurry

Rate this content

In this talk, we'll look at some of the modern options for building a full-stack React and GraphQL app with strong conventions and how this can be of enormous benefit to you and your team. We'll focus specifically on RedwoodJS, a full stack React framework that is often called 'Ruby on Rails for React'.

29 min
08 Dec, 2022


Sign in or register to post your comment.

AI Generated Video Summary

The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out for more information.

1. Introduction to GraphQL and React

Short description:

I will talk about how to deal with React and GraphQL if you are in a hurry. In 2017, I started working on a large project that used GraphQL. I encountered frustrations in dealing with different modules and bringing them together in a cohesive way. This led to repetitive and manual work.

Well, it's definitely been a minute since I started working with GraphQL. It's been about 5 years in fact, and in technology years that's quite a while. And when I was first starting out with GraphQL I didn't really care how long it would take to work on a project or get a graph QL app up and running. But these days I find more and more that I'm in a hurry with my projects and I want something that is faster to get going with and faster to maintain. And so that's what I'm going to talk to you about today, how to deal with react specifically and graph QL if you are in a hurry.

My name is Ryan and I do a lot of things around the Web. But one thing I'm very focused on today is course lifts and course lift is course hosting for people who want to have all of the mechanics of how to put together their course landing pages, how to put together their sales information, etc. Done for them so that they can focus on making their course and we help them sell their course. Check it out at course lift on Twitter if you're interested.

So going back to 2017, five years ago, when I started getting involved with graph QL, it was an awesome time because there was just so much energy in the community around graph QL. It was fairly new. I think that it dates back to 2012 at its inception but it was around this time in 2017 that people started getting really excited about it and that excitement was really palpable. This is me at GraphQL Summit in San Francisco. I got to do a talk there back in 2017 and there was just a ton of energy in the room about graph QL. People want to put it everywhere. People wanted to use it in all their APIs, from all their frontends, and you could really get that sense at the conference. It was around this time that I started working on a large project for a brand new client. I had been working for Auth0 at the time but I started to break out and go on my own, doing consulting work and I started to work on big projects that used GraphQL in this new case of this new project. It was around this time that I was really getting my footing with GraphQL. I was trying to figure out how to work it into this project and how to make it really good for the client in particular. What I noticed is that there were a lot of frustrations that came about as I started working on this project. I could bucket these into a few different categories. The first one is that it was kind of unclear to me at the time how to deal with different modules, how to separate parts of the API into different portions, how to deal with things like, okay, I want a user's module and then I want to have a module for some other resource. How to bucket those things off and then bring them all together in a cohesive way just wasn't really clearly established. And so, because there weren't these conventions in place, you were sort of left to figure those things out on your own. And so, I came up with a convention that worked in my project, but it definitely was quite bespoke and maybe wasn't the best way to do things. This led, I think, to a lot of repetitive and manual work. I'd be copying and pasting module folders over, changing names, and then having to import things into a main file. Put all that stuff up into a make executable schema in Node. And it was just this repetitive kind of manual task that I had to deal with.

2. Challenges in Frontend-Backend Integration

Short description:

There were no good frontend abstractions for frontend backend author time integration. The integration between frontend query clients and backend schema wasn't well established. It led to bespoke and brittle solutions, with things breaking as new modules were added. File uploads and authentication were also challenging in GraphQL at that time.

And at that time, also, there were no really good frontend abstractions for your frontend backend author time integration. I remember that it wasn't really all that clear how to get information when you're working on the frontend as to what the backend could offer up in terms of resources or fields on your resources. And so this integration between your frontend query clients and your backend schema, it just wasn't all that well established at that time how to make those things work well together. So what this led to really was a set of bespoke and brittle solutions. I put together things that I thought worked well in the application and it turned out that these were a little bit brittle. So things like things breaking as I would add new modules, forgetting to import one of the new pieces of the schema into my main file where I make the executable schema. Things like having to deal with file uploads and authentication. All these different pieces of the application that are fairly standard in most places, just weren't all that standard in GraphQL at that time.

3. Advancements and Benefits of GraphQL

Short description:

Adoption of GraphQL has grown, with more large companies and developers using it. Technical points have improved, including better server libraries, conventions, and tooling. Integrations between code editors, front ends, and back ends have improved. Code generation has made code modifications easier. Type safety has been a significant benefit, allowing for better author time type safety.

Things have definitely gotten better over the years. Adoption has grown. More and more large companies are using GraphQL and more developers everywhere are trying it out. I think nearly all the technical points of GraphQL have gotten better over the years. We've got better server libraries these days. We've got more of them in fact. We've got better ways to arrange these conventions across our projects. Tooling is better all around. We've got integrations from code editors and we've got integrations between front ends and back ends at author time now, which is great. We've got things like code generation, which helps to make modifications to our code in an easy way. And ultimately, type safety has really been a big benefit of all of this. Being able to know the types that are available on the GraphQL API and then being able to use those across the application stack has been really beneficial for author time type safety.

4. Challenges and Ideal Experience with GraphQL

Short description:

New GraphQL developers often find it challenging to understand the different pieces and where GraphQL fits into the stack. Working with other APIs and integrating them can also be a challenge. Focusing on early wins and demonstrating the clear benefits of GraphQL can help drive adoption. The ideal experience is to easily see the benefits of the client-server relationship without needing to understand all the mechanics. RedwoodJS is a framework that brings together different technologies and offers conventions for consistency.

But I think there's still some room for improvements and I think that's because new GraphQL developers, they're often left confused. I've talked to many GraphQL developers who just have a hard time understanding all the pieces at play when they're trying to get started. And I think that's because the learning loop for GraphQL can be quite challenging. Needing to figure out like what a schema is, what a resolver is, and how to interact with those two things from the client can be a bit challenging. This question of like, where does GraphQL fit in the stack can be one that is challenging as well. Some people think that you should put GraphQL between your server and your database, for example, whereas others think it's strictly from your client to your server. And so informing new developers on where GraphQL really should fit into your stack can be a challenge.

How do you work with other APIs when you're dealing with GraphQL? How do you work with APIs that aren't built on GraphQL, trying to integrate those? And then what tools are needed to make the whole stack fit together? And that can be a challenge for new developers as well. And so I think if we can get early wins, early wins in the sense of being able to figure out the clear benefits of GraphQL in a very quick way, I think that it's possible then to get developers more excited about GraphQL. And so if we want more GraphQL adoption, if we want more people to be trying it out and using it in their projects, I think that focusing on those early quick wins is a critical piece of it.

So in my mind, there is an ideal experience and it kind of looks like this. We should have the benefits, the clear benefits, of that client-server relationship be more easily seen at the outset without having to think about all the mechanics. So without having to think about, well, what's the definition exactly of a schema? What does a resolver mean? What is the client piece? What is that all about? Instead, being able to show the clear contract that exists between those things and being able to do so in a way where the developer doesn't need to think about all the internals and the mechanics, I think that is a very big win. Having a way to be able to handle other pieces that you would find in any other kind of environment, I think is important too. Things like authentication and authorization, file uploads, those sorts of things being able to have a clear way to show how to do those things because they're necessities in applications. I think that being able to demonstrate how to do those things early and easily is an important part. And then automatically be informed about the GraphQL schema across the stack. So getting type information from the GraphQL schema that exists, being able to use that type information to inform ourselves at author time, and having an easy way to do that, I think is key. There are numerous ways that this is made easier these days. There are more and more frameworks, more and more kind of getting started packages out there that help with this sort of thing. But the one that I'll talk about today and the one that I think is probably the best way to bring this experience to life is a newer framework called RedwoodJS. RedwoodJS is this highly opinionated framework. It brings together lots of different pieces of tech into a very cohesive and very nice to use way. And one of the things that I love about it is it offers a lot of conventions and patterns that make it really easy to have consistency across an application, especially if you're working with multiple developers. And it's a very nice framework that brings together a lot of great tech that we'll touch on today.

What does a Redwood app look like? Well, it brings together these items. We've got React, GraphQL, Node, Prisma, Storybook, and Jest. Those are the main pieces. There are some others as well. And it brings these technologies together in a way that is super cohesive and super easy to get started with and to go beyond with.

5. Redwood Features and Benefits

Short description:

Redwood provides a mono repo approach, generators for code generation, scaffolding for CRUD operations, authentication out of the box, routing solutions, layouts, code mods for easy upgrades, monorepo support, and custom patterns like cells. It simplifies component and page generation.

We don't have to worry too much about these pieces. You know, as our application grows, they just keep working and they work very well.

When it comes to a Redwood app, we've got two sides. Redwood apps exist in a mono repo, in a Yarn workspace. We've got a web side, and we've got an API side. And so this mono repo approach is great because it allows us to work within a single project, but work on both sides, the web and the API side.

And so the question often is around Redwood, what does it do? Does it just kind of like install a bunch of packages for us, for those technologies? Does it just give us a package JSON and then we install all those individual pieces of tech? And the answer is no, it has a lot more than it does. It gives us a huge set of generators, which saves a ton of time generating code. We get scaffolding for things like being able to take a model and then be able to give ourselves the whole CRUD story around it. So all of the pieces of schema that we need, resolvers that we need. And then also all of the front end parts that we need as well, to be able to do CRUD. We get authentication out of the box. So you know, typically if you're working with authentication in GraphQL, you might be reaching for a custom directive. We get that stuff automatically with Redwood. We get routing solved for us with Redwood. We get a very nice implementation of a router within the React layer with Redwood. It's a very smart abstraction, works very well. We get things like layouts, you know, a convention for having an application shell, for example, that can be used across the application. We get code mods. When it comes time to upgrade the Redwood version that you're on, oftentimes there's code that needs to be updated across the application, and we can just run a simple NPX command to get that code updated across the whole app for us, which is great. We work within monorepos. It makes things much simpler when we're dealing with a single repo for the front end and back end of our application stack, rather than having multiple pieces that we have to worry about, you know, committed to different repos and deployed in different ways, et cetera. And then the thing I love most is just custom patterns that Redwood offers, things like cells, which we'll get into. Cells are this abstraction that gives us a way to handle the whole lifecycle of a CRUD operation. And we're going to see that in some more detail. Generating components is very simple. We use a yarn command, so it's yarn Redwood generate components and whatever your component name is, for example. We get the same thing with a page. We would have a component that might just be an isolated bit of a UI that we might be working on. We might also want to have a page, which is kind of like a larger shell where our components go.

6. Generating Layout and Starting a Redwood Project

Short description:

We generate a layout as an application shell with pages and components. If dealing with a server resource, we can generate an SDL to get a full GraphQL schema and resolvers. Let's see Redwood JS in action by creating a new project with Yarn. It installs dependencies and generates types. CD into the project to explore the website and API sides.

And then we might want to generate a layout as well, which is going to be a kind of an application shell. You can think of it like that, which ultimately offers up something that looks like this, having our app shell with any number of pages that might be in it.

And then those pages themselves would implement various components. And this is a pretty typical way that an application is laid out. You've got like maybe a nav bar and sidebar in your layout, then you've got pages inside that can be navigated to and then components that do the work of the application.

Then if we're dealing with, you know, a server resource, something that would reside as a schema bit on our server with a resolver, we can target an SDL to be generated. So it'd be yarn, red would generate an SDL, giving it a name. And then we would get a full GraphQL schema, a full set of resolvers and we would be able to use it immediately with GraphQL calls.

So that's a lot of the theory. Why don't we see Redwood JS in action and we can see how GraphQL really shines within a Redwood app. So when we're dealing with Redwood and we want to get started with a new project, we can do so with Yarn. We can do Yarn create Redwood app and then give the app a name. Let's call this one GraphQL Galaxy. And then I'm going to say I want TypeScript. Typically this is what I always do. You know, TypeScript is what I use by default, but you can get Redwood in a standard JS flavor if you want as well. Just don't put on the dash dash TypeScript at the end.

When we do that, we're going to get a new application started for us. It's going to install all sorts of dependencies. It's going to go through and put together all of the packages that are within a Redwood application. So React, GraphQL, we've got Storybook, Jest and more. And it's going to put all of those things together for us into our new package. It's going to run Yarn install, and it's going to generate types right off of the bat. So type generation is something that happens automatically within Redwood JS, and that's going to happen for us right here at the installation phase as well. So we'll give this just a minute to run, and then we'll hop into the project and see how to work with GraphQL in it.

All right, we are all set here. So I'm going to CD into GraphQL Galaxy, and let's open this up in VS Code. And we'll give a really quick tour here of what's in the directories. So as I mentioned, we've got two sides. We've got a website and an API side.

7. Setting up Galaxy Page and Model

Short description:

Here's our website and the API side. Let's generate a page called 'galaxy page' and set up a model for the galaxy resource on our backend. We'll have fields like id, name, description, created at, and updated at.

Here's our website, all of the stuff that goes into the client portion of our application. Then here's the API side, and this is where stuff like our database models reside with Prisma, and it's also where we're going to manage our GraphQL pieces. So the first thing we might do is we might fire this up and take a look at what it looks like in the browser. For that, we can do Yarn redwood, or if we want to, keep it short, rwdev. And when we do, we are going to have a new project over in the browser that we can look at.

So this is the main splash page for Redwood. We don't have anything yet in terms of pages, but we can generate one and let's do that right now. Let's go and generate a page. To do that, I'm going to open up a new terminal, and I'm going to do Yarn redwood, or just rw for short. Generate a page and let's call this page our galaxy page. And we'll see what this looks like over in the browser. When we generate the page, it goes into the web directory, if we go to Source, into Pages, there's our galaxy page, and it's got things that we are interested in, like our React component that makes up the page and also a test that comes along with it for free, and a Storybook story as well that we can work on.

Over here, our page is showing up, let's navigate to it. Here is our galaxy page. So for this page, maybe we want to have a galaxy resource on our backend that we can work with, so something in our database, a resource that we can do some crowd operations against. With that, let's come over here, back over to the terminal, and we are now going to use something called a scaffold. But the first thing we have to do is set up our model. Let's come to the API directory, and we will go into our model, which is going to be under DB, schema.prisma, and what we'll do is we'll take out this example that comes with the Redwood installation, and we'll give ourselves a new model called galaxy. This is going to be like a table which will hold galaxies. So maybe the Milky Way, and Andromeda, and all the other ones that exist in the vast universe. Let's start by having an id field here. We will just make this an integer for now, and the default value can just be auto increments, so we'll auto increments that id. We'll want to say that this is also the id for this particular table. We might want a name. The name can be string. We might want a description, which will be string as well. And then typically we want to keep track of when a resource was created. So created at can be a field. That is a datetime type, and the default can be now. And then maybe updated at can be there as well, and we can track when updates happen.

8. Setting Up CRUD Operations in Redwood

Short description:

That's a datetime field, and we can use the updated at decorator to automatically get those values. We have a galaxy table in SQLite as our database. By running the generator, we get everything wired up, including the database and the galaxy table. The scaffold command creates layouts, routes, and components for adding and editing galaxies. The API directory contains the galaxies.sdl file, which provides the GraphQL schema for managing the resource. It includes fields like ID, name, and description, and supports queries and mutations. Redwood also provides authentication by default, making it easy to protect our resources.

That's a datetime field, and we can use the updated at decorator so that we can automatically get those values. So we have a galaxy table, and we are using, in this case, SQLite as our database. If we run installation on this, we should get everything wired up.

So let's, I should say if we run our generator for this, we should get everything wired up. So we can do yarn redwood prisma db push, that should give us our database. So there's our database, dev.db, and it's going to have that galaxy table in place now. And so what we can do to give ourselves a really easy way to work with data here is we can do yarn redwood scaffold, rather generate, scaffold galaxy. Let's run that command and we'll see what we get.

So we have got a layout. We've got routes. We've got all sorts of stuff. If we go to our routes file here, this is our routing file at the react level. We've got a whole bunch of new paths. We have got a path where we can add a new galaxy, we've got a path where we can edit an existing one, and all sorts of stuff that points to different components that have been created for us. If we take a look within our web directory. So we've got a new page here which is a galaxy page. I created an initial page called galaxy, which we could probably get rid of now, since we have another dedicated resource called galaxy page. of components that fit underneath this galaxy resource, which will give us all of the stuff we want to do for managing CRUD.

If we look in the API directory, we've got a bunch of stuff as well. For example, galaxies.sdl. So this is the GraphQL schema on the server that we want for managing this resource. We can see that immediately it gives us what we might expect based on an initial kind of sampling of this model that's in the database. Taking the fields that are on this model, we can interpolate here that we might want to have ID, name, description, all of these things available as parameters on this object. We get queries for galaxies, plural, single galaxy by its ID. We get an ability to do mutations right away. And if you notice here, we are requiring auth right away. So we've got this decorator require auth. If we don't want that, we can choose to skip auth, which is useful at develop time. But it's a very nice feature of Redwood that it automatically will give us authentication to protect our resources in case we forget, for example. So we've got everything in place here to give ourselves a full set of CRUD operations.

9. CRUD Operations with Redwood Scaffold

Short description:

In the services directory, we have resolvers for CRUD operations. After adding a new galaxy, we can perform various operations like editing, saving, deleting, and showing the record. Redwood provides these operations automatically through its scaffold generation.

If we look in the services directory here in galaxies.ts these are the accompanying resolvers that will be used to do all this CRUD. So why don't we take a look over in the browser again. If we refresh, there's nothing on the page here. And that's because we need to get ourselves to a spot where we can edit it. So if we go to galaxies slash new, here we go, we are able to add a new galaxy in. In Milky Way home. Let's call this home as a description. We'll save this. There's the record in our database. We can edit it to be something else. We can save that. We can delete it. We can show it. We've got all sorts of operations that are just given to us for free by Redwood by virtue of generating this scaffold.

10. Solving GraphQL Parts and Generating Queries

Short description:

All of the GraphQL parts are solved for us just by running a command. The generated GraphQL query asks for all the fields on the model and sets up the states for CRUD operations. It also handles successful operations, loading states, empty states, and failures. The accompanying server pieces are automatically generated.

The important part that I'll hone in on here is that all of the GraphQL parts are solved for us just by virtue of running that command. So, for example, if we go to our components directory to Galaxy and then we go to Galaxy cell, here is our GraphQL query that was generated. It asks for all of the fields back that we've got on that model. It sets up all of the states that we might be in for doing a crud operation. What if there is a successful operation that happens? It sets us up for that. What if we are in a loading state? What if we're empty or there's a failure? It gives us those as well. And then the accompanying server pieces for this, like we already looked at, are already there, just generated automatically.

11. Getting Started with Redwood

Short description:

Redwood provides an easy and automated way for developers to get started with GraphQL. It generates the necessary code automatically, eliminating the need to spend time on syntax and resolver setup. Developers can focus on understanding how the different pieces operate together.

So, when we're thinking about a way for developers to get started with GraphQL in a very low-friction way, a very easy way where they can just start to see the benefits of GraphQL itself, I think that Redwood provides a very clear path for that. Things are generated automatically. We don't need to spend time figuring out exactly the syntax of the SDL piece that we might need, how to tie up a resolver to it, how to put the query piece in. It's just done for us automatically. And then we can spend time figuring out how all of these pieces operate together. But that very easy way to get started is done for us, which I think is a very big win.

12. Conclusion and Call to Action

Short description:

If you're new to GraphQL, check out for an easy getting started experience. If you're an experienced GraphQL developer, recommend Redwood to others for a clear path to benefits. My name is Ryan, founder of Courselift. Check out or Courselift on Twitter for course hosting.

So if you're new to GraphQL yourself and you like what you've seen in terms of a clear getting started path for it, check out and it's as easy as we showed today. Or if you're an experienced GraphQL developer and someone you know is interested in GraphQL, I might recommend that you tell them about Redwood so that they can have that very easy getting started experience. Get the mechanics out of the way, get a very clear path to just getting the benefit first and then figure out the rest after. Thanks very much. My name is Ryan and once again I am the founder of Courselift. If you're interested in course hosting that helps you market and sell your courses, check out or Courselift on Twitter. Thanks very much.

13. Poll Results and Generating Code

Short description:

The poll results showed that most people answered 'generate schema model' and 'generate SDL model.' However, the correct answer is SDL, which allows you to generate a full set of CRUD resolvers for your backend. By running 'yarn redwood generate SDL' with your model name, you can automatically generate the necessary code.

Hey Ryan, welcome. Thank you so much for being here. Just a reminder to the attendees, you can ask your questions to Ryan on Discord and the Andrew Meda Q&A channel. So yeah, Ryan, let's go ahead and start by taking a look at the results from the poll question that you asked before your talk. Sounds good. So again on Slido, we can take a look and see. It looks like most people have answered, about 50% have answered generate schema model. Closely behind is generate SDL model. So what do you think about those answers? I think people were on kind of the right track, but it looks like the correct one was voted lower than the incorrect one. It is SDL, to get yourself a full set of CRUD resolvers, of your SDL for your backend. So if you have some model in your PRISMA schema, you can do yarn redwood generate SDL, and then your model name, and then you get all that code generated for you.

14. Differences from Other Frameworks

Short description:

Redwood brings together established technologies like React, GraphQL, Jest, and Storybook, providing a cohesive way to use them without the hassle of wiring them together. Unlike Next.js, which is more focused on React, Redwood offers a specific way of using React and a backend, but with fewer tools. It is closely related to Blitz, providing commands to scaffold an app and easily tie together various pieces. Redwood differs from frameworks like Angular as it handles all aspects of the full stack, while Angular is only for the frontend.

Awesome. Yeah, it sounds like a really great way to just get things rolling and give you everything that you need. So, great. Awesome.

Well, let's go ahead and start with some of the questions that we're seeing. The first is, how does redwood differ from other frameworks and meta frameworks, things like next, or blitz, et cetera.

Yeah, so redwood, it's an interesting kind of concept. It brings together various pieces of technology that are already established and are well known. So, of course, like we saw in the talk, React, GraphQL, things like Jest, things like Storybook. It brings these altogether and gives you a cohesive way to like, use them without much fuss, right? But one of the most difficult parts I think, about starting a project, that you wanna use all those pieces of technology in, you gotta wire them all together, and you gotta follow docs to do all that. Redwood just solves that for you.

I would say like Next.js, for example, much more focused on React. Of course, you can do API kind of things with Next, but Next doesn't have an opinion so much about how you would put GraphQL into the mix, for example. It surfaces a way for you to have a front end and a back end, but is less opinionated perhaps in that way. Still opinionated in the fact that it gives you kind of, you know, it's own domain specific way of using React and using a back end, but brings together fewer of those tools.

I would say Redwood is much more closely related to something like Blitz. Where Blitz has similar goals, it gives you, you know, commands to run, to scaffold out an app for yourself. It gives you a way to tie together various pieces very easily. So Redwood is kind of similar in that vein to Blitz, but with its own set of opinions, et cetera. And then if you look at other frameworks, I mean, if you, I mean, maybe you call React itself a framework, some people would say it is, others say it's just a library. But it differs in that way because React is just for the, you know, the user interface for the most part. And then, you know, same thing with frameworks like Angular, for example. You would more so see Redwood doing all of the stuff across the full stack for you. Whereas Angular's just for the front end. So I think that's a little bit of how they differ.

Yeah, it's interesting. I think if you look at frameworks, libraries, you know, utilities, like APIs, and you think about a few vectors around, is this front end, back end, full stack? Is this opinionated versus non-opinionated? And is this more of a library versus a framework where it's going to be very directive in how you use it? Yeah. So I think it seems to be like an interesting overlap across those three vectors. If you want to get up and running very, very quickly, have it cover as much of the stack as possible. And then also have those guidelines in place for you to be able to make decisions that are in line with the best practices.

15. Deploying to Serverless and Redwood Features

Short description:

Redwood is targeted towards easily deploying to serverless, making it super easy to work with serverless. Generators in Redwood offer significant productivity gains by generating a whole bunch of code for you. Redwood's upcoming feature is decoupling authentication from specific providers, providing more flexibility. Thank you, Ryan, for your amazing talk!

It covers a lot of those use cases, so to speak. For sure. And, and one thing that was important to Redwood at the outset, is that it be targeted towards It's easily deploying to the, in a JAMstack sense, so deploying to serverless. Where, without really any fuss at all, you would deploy your GraphQL endpoints to a serverless function. You could deploy any, kind of individual functions you might be wanting to work with as serverless functions as well. So just, like, super easy to work with serverless too. Yeah, and we're seeing like from an architectural standpoint, teams that can work in that environment, they're able to move pretty quickly, which is great. So awesome.

Another question is kind of in line with that, actually. So which features of Redwood offer the most productivity gains? Yeah, for me it's generators. Those are pretty huge. You know, there's this argument to be made that generators might not be the most important thing for a framework because once you've generated your code, you're then kind of maintaining components you've already built. And so you're not, maybe, always using generators. But for me, especially when starting a project, being able to scaffold things out and generate, get a whole bunch of code just done for you is huge. And I've started using, I got on the train with like ChatGBT giving me code now. I am using Copilot and stuff like that. So the more code that can be written for me, I'm all for it. I'm not a purist that says I've got to write all my own code. I will happily let the computer write the code for me. So Redwood is great for that, you know, just generating code to get you out the door. And then you make the appropriate changes that you need, of course, to your components and build from there. So it's a huge, it's a huge boost. Awesome.

And one last question we have time for. Is there any feature that's coming up that you're looking forward to? Well, there's talk now about kind of handling authentication in a bit of a different way. Redwood has been their authentication model just quickly has been kind of strictly tied to a provider. You can use many different providers, but it's pretty well coupled to that provider that you might choose. And now there's work to be done to decouple authentication that has traditionally been coupled to a specific provider. So I'm looking forward to that. Awesome. Well, can't wait to learn more about that. And so thank you so much, Ryan, for answering our questions and for your amazing talk. We really appreciate you being here. Absolutely. Happy to be here.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick
easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data
use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time

React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?
There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.
Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.
You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.

React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.
Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q