Rock Solid React and GraphQL Apps for People in a Hurry

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Slides
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'.

This talk has been presented at GraphQL Galaxy 2022, check out the latest edition of this Tech Conference.

FAQ

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. It provides a more efficient, powerful, and flexible alternative to the traditional REST API. It was developed internally by Facebook in 2012 before being publicly released in 2015.

Since its inception, GraphQL has seen significant adoption and improvement. Enhancements include better server libraries, more efficient front-end and back-end integration at author time, and the introduction of features like code generation and type safety, which have streamlined development processes.

New GraphQL developers often struggle with understanding the schema, resolvers, and their interactions with the client. The complexity of integrating GraphQL with existing APIs not built on it and the initial setup of the technology stack can also pose challenges.

RedwoodJS offers a range of productivity tools including code generators, scaffolding, integrated testing, and out-of-the-box authentication solutions. These features allow developers to quickly set up and scale applications while maintaining best practices.

GraphQL provides precise data fetching, allowing clients to request exactly what they need, reducing bandwidth usage and improving load times. Its strong typing system helps catch errors during development, and its single endpoint simplifies the logic needed to interact with multiple data sources.

A typical RedwoodJS application uses a monorepo structure with two main sides: the web side (front-end) and the API side (back-end). This structure allows seamless integration between client and server code within a single repository, facilitating easier management and deployment.

RedwoodJS is a full-stack framework that integrates technologies like React, GraphQL, Node, and others into a cohesive development experience. It simplifies the use of GraphQL by automatically generating schemas, resolvers, and client-side integrations, significantly reducing boilerplate code and setup time.

Ryan Chenkie
Ryan Chenkie
29 min
08 Dec, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
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 RedwoodJS.com 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 RedwoodJS.com 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 Courselift.com 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 RedwoodJS.com 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 Courselift.com 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

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
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 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
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.