Why Redwood Adopted React Server Components

Rate this content
Bookmark

Redwood, an open source full-stack app framework, has gone all-in on React and React Server Components. Why? Despite RSC’s early stage and complex implementation, Redwood is uniquely positioned to capitalize on RSC capabilities, enabling exciting new features, possibilities, and DX. 

33 min
13 Nov, 2023

AI Generated Video Summary

Redwood is a full stack web app framework built with React, GraphQL, and Prisma. It prioritizes conventions and maintainability, and collaborates closely with the React team. Redwood offers full-stack features, including real-time functionality without WebSockets. The Bighorn Epoch is a new phase in Redwood's roadmap. Redwood is excited about the possibilities of React Server Components and wants to collaborate with the community.

1. Introduction to Redwood and React

Short description:

I get the after-lunch crowd. We're going to learn about Redwood. Let's talk about the elephant in the room. Some of you don't know what Redwood is, so we're going to address that. We're also going to talk a lot about RSCs. I'm on the leadership team at Redwood. We love to help make people successful. React Server Components is definitely doing that for Redwood. Redwood is all in on React. There's a lot to come. We're really excited about what's happening with React.

I get the after-lunch crowd. And that's because I'm going to make you be interactive. We're going to have a really good time. We're going to learn about Redwood.

Let's talk about the elephant in the room. Some of you don't know what Redwood is, so we're going to address that. We're also going to talk a lot about RSCs. I'm on the leadership team at Redwood. I mentioned a couple of the things I do. And the most important part of the theme that draws other things together is I love, and the teams I work with, we love to help make people successful. We love to help make others successful, so that can make the Redwood Project successful. And that's a lot of what we're doing. And React Server Components is definitely doing that for Redwood. And we're also hoping that we can move some things with React Server Components forward. But first off, let's just cut to the end here. Are we getting the... There we go. I'm going to cut to the chase. I'm actually going to tell you the point before I do any of the presentation, because who knows what's really going to happen next? All you need to remember is that Redwood is all in on React. So everything I'm about to talk about, the summary at the end is that we're all in on React, and there's a lot to come. We're really excited about what's happening with React, and that's where Red... Because of where React is going, that's where Redwood is going.

2. Your journey with React

Short description:

Your journey with React. This will require a bit of audience participation. Reflect on that time in your journey with React where you felt creative possibility. JavaScript ecosystem gets us excited about what's possible.

All right. Here we go. Engaging part. All right. Your journey with React. So this will require a little bit of audience participation. It's true I actually can't see any of you right now because of the bright light, so I won't know if you're participating, but I'll be able to hear, and it'll be fun, we're going to have a good time. So if you can remember way back when, I want you to reflect on that time in your journey with React very early on where you might have felt that creative possibility. Right? JavaScript ecosystem, we love these kind of things, we get really caught up with shiny things. Why? Because it gets us excited about what's possible. So think way back in.

3. React Creativity Reflection

Short description:

Stand up and rate your creativity and unbound possibility with React. If you were a 1 when you first encountered React, sit down. If you were a 2, sit down. If you were a 3, remain standing. Reflect on your excitement and possibilities with React. Now, imagine your relationship with React and creative possibilities last week.

All right. Everybody stand up. I know you have laptops. I can see the laptop. Stand up, that's good. Yeah, these people in the front, I like these guys. That's Tom by the way. All right. Stand up, that's good. I'm going to come over to the side so I can lead a little bit.

Here's what you're going to do. All right. If you were a 1, 1 is going to mean, wait, people get to be creative, right? 1 is the lowest on the scale. Could be better. Could be worse. That's medium scale. 3 is that sense of unbound possibility. Maybe not quite that high but, you know, somewhere in there. So think back when you first discovered React, interactive UIs on the client. Now, go ahead and sit down. If you were rating yourself, your relationship to creativity and unbound possibility at the If you were a 1 when you first encountered React, go ahead and sit down. Meaning like, people got to be creative? Okay. All right. Honest people. I'm not calling anybody out, but I saw that, thank you. If you were 2, way back when you first started your React journey, sit down. Okay. Good. If you were 3, you're standing up. Nice. Somebody, one person who's a 3. What was something you were really excited to do? A sense of unbound possibility, shout it out. Something you were excited to do with React the first time. Nobody. Writing a reconciler and for like, different stuff, like React 3 fiber and like, KC fiber, those technologies were really cool and sort of got me into the head space of like, you could really do anything. You could do anything. I like it. Super nerdy, great example. All right.

Okay. Everybody, stand back up. Stand back up. One more time. Now, I want you to imagine last week. Now, you're hyped up because you're at the conference, this is not about the conference, so a week ago, or the last project you were on, what was your relationship with React and the creative possibility for it, right? So, this is like a week ago. This is recent now. So, go ahead and sit down if you were a one. Oh, wow. If you were a two. If you were a three.

4. Redwood: A Full Stack Web App Framework

Short description:

Redwood is a full stack JavaScript typeset web application framework. It aims to be the full stack web app framework and is built with React, GraphQL, and Prisma. Redwood provides a test suite, TypeScript support, a Vite CLI, and generators. It also includes features like cache enablement, authentication security, and a storybook implementation. Redwood prioritizes conventions and maintainability, and considers the database, backend server, and collaboration as first-class citizens. The Redwood team collaborates closely with the React team at Meta.

Okay. And then go ahead and sit down if you're a three, right? That resonates a lot with me. So, for those who didn't see in the room, most people sat down at two, right? Like, the creativity and possibility shifts over time. But, boy, howdy. I'm excited to show you what's happening with React server components because I hope we can open up for you not how server components work, nerdy, very interesting. But that's not what we're going after. What are the opportunities and possibilities we have?

Okay. So, first off, what is Redwood? Elf in the room, we don't know what it is. So, I wanted to go through these slides really quickly. Redwood is... Do we have the right slide? No, this was the slide. Redwood, when we first launched it, full stack for the Jamstack. That was true, true about three years ago when we launched. That's not as much true today. Redwood is a full stack JavaScript typeset web application framework. In the future, we're going to be the full stack web app framework. That's right. We're going for the title. And Tom Preston Warner, who conceived of Redwood, got it started. He built one of the largest Ruby on Rails apps in existence. You know? I feel like we got a contender. We're not there yet, but that's where we want to head.

First class citizens. What we mean when we say full stack, what you need to know is that Redwood is all these things get full attention, full integration. They get the status of being first class citizens of Redwood. I'm going to read these really quickly. React, GraphQL, and Prisma. We've got a test suite from front end to back. TypeScript. All those that yolo, yes, you can go strict. We have Vite CLI. You have generators. All kinds of things you can do with a CLI. Very Rails-like. Cache enabled. Out of the box. Authentication security. Redwood is secure by default. We consider separations of concerns. We have a storybook implementation out of the box. Very important for a full stack framework out of the box. And also, Redwood is full of conventions and a golden path to get you started quickly and to allow you to keep maintainability going as you scale. These are all built into Redwood. This is really important for us at React Summit. The database is a first-class citizen in Redwood. The backend server is a first-class citizen in Redwood. And another first-class citizen is collaboration. We are highly collaborative. We're working with the teams, building all of these tools every day. We're working with the React team at Meta on a weekly basis.

5. Redwood: Independent and Exciting

Short description:

Redwood is an independent and open source project. We're not making money on Redwood yet, but we want people to use it. It's three years old with a strong community. Startups using Redwood have raised over $75 million. Check out Puzzmo.com, a gaming app built with Redwood. GraphQL is a powerful tool, but not great for everything. Redwood offers full-stack features, including real-time functionality without WebSockets. Try out the chat app and countdown timer at Realtime.RedwoodJS.com.

They're joining us for working sessions. And we do collaboration also with our community. So we invite you to collaborate with us, as well.

Redwood today. It is an independent and open source project. It is free to use. We are not making money on Redwood, which begs the question, how will we make money? We're not making money today. I don't know, Tom. Do we have an answer to that? No, we don't know. I want people to use Redwood first. It's three years old. We've got 16 plus 16K stars on GitHub. We're already at version 6.4. You can do a first-class deploy to Fastify. So we are Fastify first, so for server full. You can also deploy service-ly on AWS Lambdas. What we know of startups using Redwood and critical infrastructure, they've raised over $75 million. They are scaling. A new one coming out you should be excited about is called Puzzmo.com. That's Orta Therix, and Orta is using Redwood and Puzzmo. And it's super fun. It's a little gaming app. Think like New York Times Crossword Puzzles, only like all kinds of other things. That's Puzzmo.com. We feel that Redwood is the best in class today. SPA framework and out-of-the-box GraphQL framework. Where's my aside? I'll do an aside over here. So aside. You've been lied to about GraphQL. I know, right? What? GraphQL is not terrible. So who knew? Now, there are things that are really hard about GraphQL, but if you can implement those out-of-the-box and get started with GraphQL and make that easy, it turns out GraphQL is a really powerful tool. It's just not great for everything. Here's some full-stack features for Redwood. I could do 20 minutes on each one of these. But this is what we mean when we say full-stack. Man, I'm so excited about these! I can only show slides, but I've got a page I'm going to send to you at the end, and you can try all these things out for yourself, including our RSE experiments and demos. All right? So that's coming at the end. Stay tuned. Full-stack features, these are the new ones to Redwood, and we are super excited about them. Redwood Realtime. Redwood Realtime, without WebSockets. Ask me how in the Q&A. Redwood JS Realtime. Go to Realtime.RedwoodJS.com and we have five apps in one. You can try out our chat app. You can try out our countdown timer. These are using subscriptions and what's called live queries with GraphQL. We have tons of documentation on this. It's really fun to use. This is great.

6. OpenAI API, Redwood Mailer, and Redwood Studio

Short description:

This is using OpenAI's API. Nailed it the first time. You can take a long time to get responses when you're hitting up that magical AI generator. This is also using subscriptions so it creates a movie based on a mashup. Who knew that a mailer could be awesome? Redwood's mailer is awesome. Redwood studio gives you full visibility and introspection into what's happening at dev time. Redwood is a full stack framework. We're best in class SPA.

This is using OpenAI's API. Nailed it the first time. I'll screw it up before I get done with this section. OpenAI's API. You can take a long time to get responses when you're hitting up that magical AI generator. You can pick some words and it tells you a story. It's really fun. Bed time with your kids. This one's good too. Pick two movies. OpenAI's API. Twice in a row, Jack. Nailed that.

This is also using subscriptions so it creates a movie based on a mashup. This is a bidding application using live queries. Go try those out. They're really fun. This is deployed on fly. I think that's using superbase for the back end. Highly performant. Really well.

Okay. Who knew that a mailer could be awesome? Redwood's mailer is awesome. Because it turns out, if you can actually do your templating inside of your framework and then preview those while you're doing development on them, then mail gets fun again? Who knew? So that's what Redwood mailer is. There's an API. You can selfhost. You can plug into other providers. This is Redwood mailer. And you're seeing the template preview right there. And also, we proxy the requests during local development. So you can actually send e-mails locally to test without hitting everybody up in your entire mail subscription database. Right? So no more interns will be sending their mail to everyone on the list. It's a test e-mail. Anyway, that's Redwood mailer.

Redwood studio. Wouldn't it be nice if you could fire up a local development app that gave you full visibility and introspection into what's happening at dev time. So this is showing we have open telemetry. You can actually see open telemetry traces during dev time with Redwood studio. You fire up Redwood studio by running Redwood studio. Right? So this is just available to you at the command line with Redwood. More things on traces. You can do things with Prisma. Graphical. It's all there inside of Redwood studio. Redwood studio is amazing. And this is what we mean when we say full stack. Does that make sense so far? All right. So Redwood is a full stack framework. There are some things that are hard with Redwood. It turns out we're best in class SPA.

7. Challenges with Redwood and the Bighorn Epoch

Short description:

There are reasons why people might not have used Redwood today. One reason is the difficulty of getting started with GraphQL. Redwood has made it easier, but it can still be a barrier for some. Another challenge with Redwood is that it may not meet all the expectations of React developers. Redwood is now introducing the Bighorn Epoch, a new phase in their roadmap.

There are a lot of use cases that we tell people not to use Redwood for if it's not SPA. Probably some of the reasons why you might not have used Redwood today.

Okay. Not everybody loves GraphQL. And I get it. There's actually some things you don't want to do with GraphQL that make it hard. I'm referring to my notes over here. One of them is... Oh, the notes are for the other... Never mind. No notes. Things that are hard with GraphQL. One, getting started with GraphQL. If you don't need GraphQL because you're a single client or small team, you don't need GraphQL for those things. And also, it turns out, there's still a learning curve. And Redwood made it really easy to start with GraphQL. We take care of all the boilerplate for you. We handle the resolvers. But it's still hard to get started with GraphQL. And frankly, this is the number one reason we think people don't use Redwood today. Is because I don't want to use GraphQL. Totally fair. Totally fair.

Another thing that's hard with Redwood is... Ah, there we go. You know what? I'll be honest. We did a good enough React implementation for Redwood because we weren't Reactive developers. Secrets out. Some of us weren't exactly Javascript developers when we started the Redwood project as well. We came from Ruby on Rails. We've done work in Python. Other frameworks. And we came in and brought the best of class that we loved and said... We want to do this inside of Javascript, and we want to do it with node. So we had a lot to learn. And frankly, we didn't do everything that this community of React developers, React first framework developers wanted us to do in Redwood. And so there's a lot of great options for the things you want to be able to do in React that are available right now. And that's why some people haven't chosen Redwood yet. It worked really well. Our conventions were amazing. But we still have some work to do.

So introducing Redwood's Bighorn Epoch. Isn't that a beautiful photo? That's really nice. So we don't do marketing around major versions. Right? So 6.7... It turns out we know the guy that did SimVer standards. So we break things. We upgrade. But we have what we call Epochs. And that's kind of our marketing and our roadmap.

8. Redwood's Bighorn Epoch

Short description:

Redwood's Bighorn Epoch is happening right now. Redwood is all in on React. We're catching up to and going beyond the React framework. We're collaborating with the React team and the community. Check out our Roadmap at Redwoodjs.com/Roadmap.

And Redwood's Bighorn Epoch is happening right now. And what was the one thing I wanted you to take away from this talk? Redwood is all... All in on React. See? Jack got it. Redwood's all in on React. So guess what the Bighorn Epoch is about? Redwood's all in on React. Man! I can see you're here. I know it's... I'm blind. Anyway. Redwood's all in on React. So that means our code and our features, we're catching up to and then going beyond. We're getting up to where the React framework... Sorry, the React Roadmap is. So Redwood is all in on React. We're gonna collaborate with you all. We're collaborating with the React team. We're collaborating... We've got Lens from the Apollo team. We're working in channels day-to-day, week-to-week with people to collaborate on making Redwood be all in on React and what does that mean, and also we're collaborating with the community. So we're bringing our communities together with other communities and that's what it means for Redwood to be all in on React. You can see our Roadmap down there. If you scan that thing, it'll take you there. But go to Redwoodjs.com forward slash Roadmap.

9. Redwood and React Server Components

Short description:

Finally, let's talk about why Redwood chose React Server Components. It's what comes after streaming and suspense. We're in for React Server Components as is the React team. The concepts and architectural design for RSC pair nicely with Redwood. RSC combines a request-response mental model of service-centric multi-page apps with the interactivity of client-centric single-page apps.

Okay. Finally the guy's gonna talk about the thing that was in the title. Right? So all of that was what is Redwood? And also, why is — I'm setting things up here to show you why Redwood and React Server Components is a really nice fit. So why did Redwood choose React Server Components? These are the three things I'm about to talk about next. It's what comes after streaming and suspense. We built a solution for streaming and suspense. I'll show you. And it turns out if we're gonna keep up with the roadmap for React, we're in. We're in for React Server Components as is the React team. But we're just — we're on the roadmap now. Also, I believe it was Sebastian wrote an article about what comes after GraphQL. There's some things I'm gonna show you about how, when you've built a framework that does first-class citizenship for GraphQL, it turns out the concepts and some of the architectural design for RSC — it just pairs really, really nicely, because they're highly related. And then, also, we're gonna talk about this thing I'm just calling Fetch Anything for Now. I'm not gonna do a deep dive on what is RSC, how to implement it. Our belief is that the framework's gonna do a lot of that for you. You'll need to understand how it works, but I'm not gonna go into the code. I've got some more on that later. You can see how the code works. We've got some good demos. But let's talk about how the React team talks about what is RSC. RSC combines a simple request-response mental model of service-centric multi-page apps — they talked about this in the panel before lunch, if you recall — with the seamless interactivity of client-centric single-page apps, giving you the best of both worlds. Right? So, being able to shift back and forth from that server-centric model to the client-centric model and to be able to, in some cases, merge those two mental models together into one use case is really nice. I'm gonna show you what that means for Redwood.

10. Redwood SSR and RSC

Short description:

Redwood has SSR capabilities with React streaming and suspense. They built a ticketing and badge app using Redwood SSR. The app allows authentication with GitHub and provides customized badge generation. Redwood now supports full server-side rendering and has switched to VEET for bundling, using a suspense router. SSR and RSC are a natural fit for Redwood.

So, first off, streaming and suspense — you probably don't know about it but Redwood has SSR capabilities. So, let me show you — we built this for the Redwood Conference, which was a month ago — this was our ticketing and badge app. And this is Redwood SSR using React streaming and suspense. We'd been working on this at the end of last year. Well, let me just show it to you, what it is, and then I'll tell you what we did with it. But check this out. Ticket.redwoodjs.com. So, it's already in there, but streamed down — that was actually a pre-rendered page. Nice little fun interactivity, right? It's your email address, and it's going to let you authenticate behind-the-scenes with GitHub. And now I've got a customized badge app. Notice I just copied that share URL, and with Redwood before, what would you expect to see here? Nothing. And what do you see now? You see all of your head OG tags. And all of that was just real time. It's that fast, it's deployed on fly, and it's using Neon for the database on this. And this is available now. So, you can do SSR with Redwood. We had a pre-render feature available before, but now you can do full server-side rendering with Redwood. We built this before we chose to do RSC. But it turns out that all the building blocks you need for RSC, we already handle those because we switched over to VEET for our bundler. We're running VEET on the server, so we have a frontend server now. We have our own router, Redwood router. We switched over and re-architected under the hood to use a suspense router. And we love what we're able to do with SSR, and RSC's a natural fit because it's going to live right on top of that.

11. RSC, GraphQL Fragments, and Redwood Server Action

Short description:

RSC and GraphQL are complementary in terms of concepts and conventions in Redwood. Redwood integrates RSC seamlessly, eliminating the need for an additional router. Let's discuss the GraphQL Fragment Pattern, which works similarly to Relay. Fragments allow you to fetch data for all components on a page with a root query, enabling automatic caching and updating. Redwood startups have successfully used this pattern at scale. We'll also explore Redwood's server action functionality, which allows interaction between server and client components.

So I talked about this before. Number two, RSC and GraphQL, like, they are very complementary both in terms of concepts, what you can do, but also because of the ways we built in conventions and this golden path into Redwood with GraphQL. RSC just makes sense in the context of Redwood, so for example, we don't need to create another router for Redwood, we'll just build RSC right into it and right on top of it.

I want to show you, really quickly, this GraphQL Fragment Pattern. This might make sense to you. For those who work on Apollo Client in the room, please plug your ears and close your eyes for just a second. And then I want to show you a Redwood implementation of Server Components with Server Actions, because I think it's true that we are the second framework to implement Server Actions behind Next. So, yeah, go Redwood. Toby, actually, go with Toby. That guy's amazing. Right, Tom? Toby's killing it.

Okay, so, real quick, let's talk about GraphQL Fragments. I know, already you're like, I didn't come for GraphQL. But this is a really interesting, high-level idea. And for those who Next and for those who Remix, this should actually look really similar. So, this is how Fragments work. This is how Relay works. You've got a parent component, and you have a root query inside of it. All the data you need for all the components on that page, you're going to go fetch it with that root component. This is how fragments work, okay? So, the parent component, it's going to go fetch the data, render, and now it has all the data it needs on the page, because it knows about these fragment queries inside of the child components, child one and child two. So, what happens? Fetch the root query, get all the data, pass those down. The fragments know what fields to ask for, so the data's there, and then in Fragments and in the GraphQL model, all of your caching, all of your updating, just happens automatically behind the scenes. Apollo Client does this really nicely. There are Redwood startups that are using this pattern at scale, and it works really well. Highly performant, blazing fast. And again, so say you update that root query with a mutation, so there's an update to the data on your page, and then everything, just in a nice little flow behind the scenes, updates and re-renders automatically. That sounds awesome, right? It can be really hard, but that sounds great. So, what if we could do that with something that wasn't GraphQL and made a little more sense inside of the React world? Well, check it out. This is, and I only get to show you 30 seconds, this is a real app you can play with later. This is Redwood server action. And a couple things I want to point out before I run the demo. Notice this is already rendering a server component and a child component. This is functionality working in Redwood right now. And what you're about to see is how we can interact with a client component. Stay on the client component and look at what happens. I'm running this now. Look at what happens with the server component, right. So the red box, outside parent is the server component. Child component, client component inside. Right, so we'll talk about a couple things here real quick. But watch, the two counters are going up separately. Did you see the fetch happen when the server component was incremented? Did anyone notice what just happened there when the page re-rendered? I'm going to run this twice. Okay, the page re-renders. That's it. And I'm going to run that one more time. Okay, couple things happen here. Actually, Tom did talk about this for 20 minutes at a keynote. I'll tell you how to get to this and go through the full presentation here. Right, there is state being managed on the client for the client component. When you fire the server action, you're seeing a fetch there, that's a server action, updates on the server, and that updates the server component, right, which then passes down in everything you need, right, both component and data is passed down from the server.

12. Redwood Cell and Server Cell

Short description:

I'm going to run this one more time. So, does anyone notice what happens when the page refreshes? Where's the state for the client component happening? On the client. Server actions are amazing, you're going to want to use them. Next up, fetch anything. A Redwood cell convention is effectively a higher order component that does everything you need in one component for fetch and component state. This is what startups are using when they build with Redwood today. This is a Redwood cell component. What happens if you use a server cell? This is absolutely possible. All of a sudden, with server components, Redwood goes from GraphQL to being able to fetch from anywhere, from any data source, including just a direct data query from your database or any other data source. So what's coming for Redwood with RSCs? What happens if you don't need GraphQL to get started? Or GraphQL at all? Thank you.

I'm going to run this one more time. So, does anyone notice what happens when the page refreshes, right? That's the mental model I want you to get. Along with this is just like magic in general. So client components being integrated. Where's the state for the client component happening? On the client. Okay? Page is about to be refreshed. Watch the server counter. Server counter did not change. Why? Where's the state for the server counter? What do we call state on a server most often? A database. All right, you're going to need a database. Redwood has a database. But isn't that amazing? Okay, sorry. I just think we think this is really cool. All right. So, anyway, it turns out that RSC goes great with GraphQL and server actions are amazing, you're going to want to use them. They're great. Okay, next up, fetch anything. We have a convention called a Redwood cell. Let me show this to you with GraphQL. Well, what happens if we create a Redwood server cell with dot, dot, dot? This is what I want to show you next. So fetch anything is going to make sense here in a second. All right. I can't even see your hands. I was going to ask you to show of hands. A Redwood cell convention is effectively a higher order component that does everything you need in one component for fetch and component state. All right, so what you're seeing here, lot of code. Very simple. You have a GraphQL query. That is your fetch. And then you have, you see, the components for loading, empty, failure, and success. Right? So all of these are handled. So the whole life cycle of state is handled inside of one client component. This is real. This is what startups are using when they build with Redwood today. This is a Redwood cell component. All right? Notice where that is. So what happens if you use a server cell. Let's just say, for example, you want to import the database client. And then instead of doing a query through GraphQL, you just do a database query right there inside of a server component. Right? This is absolutely possible. This is a big aha moment for us with Redwood server cells, maybe. This is where we're starting to think, what if. So this is possible. This is probably not what you're going to want to do. But all of a sudden, with server components, Redwood goes from GraphQL to being able to fetch from anywhere, from any data source, including just a direct data query from your database or any other data source. Makes sense? So you probably don't want to do this, though. So what's coming for Redwood with RSCs? This is huge for us, because I told you what's one of the reasons people don't use Redwood right now? GraphQL. So what happens if you don't need GraphQL to get started? Or GraphQL at all? Would you guys try Redwood then? Come on, raise your hand. I know you will. OK, OK, so anyway, thank you.

13. Redwood's Server Components and Collaboration

Short description:

We're excited about the possibilities of Redwood's server components and the transparent API. It allows fetching from any data source, keeping it sane and enabling various use cases. The new transparent API is coming, and we want to hear your ideas. React Server components have sparked our creativity and excitement, opening up possibilities for Redwood. We want to collaborate with the community and learn what you envision for React Server components. Connect with us on Twitter or LinkedIn and join us in the Q&A.

Jack is with me up here. That's good. That's good he's in the front row. So one, we're really excited about what's possible here. This is something we stumbled into. This transparent API, in addition to GraphQL, is something that we are going to figure out and make very powerful in first class in Redwood's server components.

This idea of fetching from any data source, we want to keep it sane, though, is going to make it really possible to do all kinds of things with Redwood's React Server Component implementation. And just real quick, this is how we see keeping it sane. How might your data flow? If you have a database, which you might not need a database, your services, your data for your database will go into your services. That's a concept in Redwood. We have a convention for services. That's where all of your back end logic goes. So that exists in Redwood today, your services where your back end logic will go for whatever data source you're hitting, but the data would flow from the database, in this case services. And your services, that is where the data flow would flow into your web. So you're going to be importing a function from your services. It'll be type safe across your whole app and you'll have some sane ways to work with whatever data source that you want inside of your Redwood React Server components. We're super excited about that.

All right. So a new transparent API is coming to Redwood. We don't know what the design on that's going to look like, but we'd love you tell us what you want it to do. And the person to talk to is Tom, he's in the room. So last, last thing. This is the bonus. Like this is really why Redwood, this is the why why, why Redwood's choosing React Server components. Because React Server components got us to start asking, what if? And remember that whole creative possibility thing that I talked about at the beginning? Like React Server components has been that for the Redwood team. It has caused us to ask what if. It's caused us to get really excited about, to get creative about the possibilities. It's opened up for the Redwood framework. And again, Redwood defines its success by making others successful. So seeing what startups are going to be able to do and what they're able to build, or any builder is going to be able to do with Redwood because of React Server components, like that's our jam. So we are really excited about it. So if you would do us the honor, this is a part of collaborating with the community. Like I said, this hasn't been our world, React in this community. You all have been embedded here. And you know much more deeply what's possible with React even than we do. So will you tell us, like right now? I don't know, pull out that phone or that gadget with you. And would you, like, if you're into the app forum, and your name is Twitter, that's mine, the David Price and Tom at Majumbo. Would you tell us, what's your what if? Like, what if React Server components could do bill on the dot, will you send that to us? Like, we want to know. Send it to us on Twitter. I'm also on the LinkedIn. I don't know how you tag me there, but I'm David S. Price. I'm not the baseball player. I'm not the motivational speaker from Australia. I'm not the British footballer or the US Congressman. I'm the David Price. Sounds pretentious, but just tongue in cheek. But we want to hear. Hang out with us afterward in the Q&A, like we want to know. A couple of next steps for how you can join us.

14. Redwood Workshop and Choosing Redwood over Next.js

Short description:

Amy Dutton will present a workshop on full-stack React and Redwood. The Notion document has all the details and demos. Redwood is all in on React. If you want conventions, a golden path, and hackathonability, choose Redwood. React server components fit naturally into Redwood, and the Redwood router was built for it. Redwood is an independent open-source project.

Amy Dutton, who's also on the leadership team of Redwood, she is going to be presenting a workshop in two days on Thursday. That's one of the free workshops, if you bought a ticket here. It's how to do full stack for React, but she's going to be talking about Redwood, how to do full stack React, and also what's coming with React server components. She'll be talking about that.

And then here's the thing, see that down there? Redwoodjs forward slash React Summit. That is a Notion document that has everything I just talked about in it. We have quick demos you can fire up for every React server component example we have right now. You want to play with server actions, go there. Tom did an incredible keynote at our conference. He's going to be writing. We'll have a blog coming soon. So you'll be able to see, if you want the deep dives, we're posting all that on the Notion doc. So go to Redwoodjs.com, React Summit.

And I took three minutes less than I thought I would. So we've got time for questions. We have three minutes. Thank you so much. I hope you know that we're all in on React server components. Did you get that point? Oh, sorry. We're all in on React. That's it. That's all I wanted you to know. All right. Well, there's another RSC framework out there. Yeah, Next.js. So for all these folks in the audience, is your elevator pitch on why they should choose Redwood.js over Next.js? Yeah. So let me start from here. You might end up using both. So right now, there's a lot of Next apps that are actually powered by Redwood's API. So that's a real thing. If you want to use the Vercel platform, it is impossible to beat, right? Like, Vercel's platform. So when I think of, like, what does a Next full-stack application look like? Really, it's like Next plus Vercel, right? Like, that's full-stack for Next. And I mean, frankly, they're the only one. But if you're going to start... So one, if you want conventions and you want a golden path and you want what we're calling now, like, something that Next has done really, really well is what I call hackathonability. That was in my notes, I should have got over there. Like, Redwood is not very hackathonable right now, right? But there's gonna be things you can do with Redwood out of the box with React server components that make it much more of a, like, getting started early application. So why choose Redwood? We think React server components is going to fit more naturally into Redwood than it will any of the existing frameworks right now. And one of the reasons for that you can see right now is, like, Redwood router was built for it. I didn't talk about that. You don't need another app router. Like, you're not gonna have choices. You're not gonna have to choose the page router or the app router. Like, that'll all be one thing. You can do both within one context with Redwood. Also, Redwood is, Remix is gonna have some similar challenges as well. Now they'll get there, those are all great frameworks. And then the other thing is, like, Redwood is an independent open source project, right? So I think that's gonna speak to a lot of people in terms of, like, wanting to feel like, I wanna be a part of the open source, I wanna drive some of the vision behind it. We're a lot smaller. I mean, NeXT is paving the way, and I don't wanna say anything.

15. Getting Involved with Redwood.js

Short description:

If you want to get involved, Redwood offers a different vibe and a unique community participation experience. You can influence the direction of the project. To get started with Redwood.js, the best way is to follow the Redwood tutorial, which is like a full-stack development course. Check out the Redwood forums for examples and updates on the latest features, including React's server components. Join the community and try out the new features by following the steps and setup commands provided in the forums.

We're actually learning from them how to do this, right? So to put that out there. But, yeah, if you want, it's gonna feel different. There's gonna be a different vibe, and you're gonna be able to have a different kind of participation in the community, which is something that we are all about. And you're gonna have a different feel for how you can actually influence the direction of the project, as well. So I think those are some really great reasons to get involved.

And, frankly, I don't know. I know that after the after-party, people are gonna be back in the hotel. They're not gonna be sleepy. They're gonna be like, hey, I wanna try out something. How are they gonna get started with Redwood.js? Should they go to that Notion document? Are there some good sample apps there to start with? Yeah. Like, how do they start out with this?

Thank you, Jack, that's another great question. So, right now, the best way to get started with Redwood is the Redwood tutorial, which is more like a course. It's actually amazing if you wanna learn full stack development and GRaphQL. We are in between right now. We have the same problem that the React team does on a much, much smaller scale, which is all of this is working in Canaries and Experimental. I highly recommend you go to our forums. So, community.redwoodjs.com, and that's where you'll see these examples. You'll see a forum post that's just about RSC. Toby is dropping all the development change log there. The example apps are there. So, right now, if you go to our docs, same thing that's happening in React. All of our docs are for stable 6.4. If you want to play with all these new things that are happening with React's server components, those are in our Experimental Canary versions, and all of that is happening in real-time on our forums. But that's where we're committing to the community to give you updates on what's happening right now. The best place to try those things out is drop into our forums and run through the steps and set up commands from there.

All right, fantastic. Was that a good answer? Yeah, it was great. All right. Jack liked it. Give it up again for Dave Price. Thank you. All right, buddy. Thank you.

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

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.
React Summit 2022React Summit 2022
20 min
Find Out If Your Design System Is Better Than Nothing
Building a design system is not enough. Your dev team has to prefer it over one-off components and third-party libraries. Otherwise, the whole effort is a waste of time. Learn how to use static code analysis to measure if your design system wins over the internal competition and data-driven ways to improve your position.
TestJS Summit 2022TestJS Summit 2022
25 min
CCTDD: Cypress Component Test Driven Design
The first part of the talk will focus on a variety of patterns when using Cypress Component Testing and TDD to create React components. The code samples will be from Angular's Tour of Heroes to make the content relatable to a wider community. Currently I am working on a GitBook rewriting it in React using Cypress Component Tests, there should be plenty of content to distill into the talk.The second part of the talk will focus on test strategies, types of testing and where to apply them, and finally compare & contrast them to the familiar industry approaches.We will finish with key takeaways, sample application repos to help with learning, and rollout strategies.

Workshops on related topic

React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
React Summit 2023React Summit 2023
31 min
From Idea to Production: React Development with a Visual Twist
WorkshopFree
Join us for a 3-hour workshop that dives into the world of creative React development using Codux. Participants will explore how a visually-driven approach can unlock creativity, streamline workflows, and enhance their development velocity. Dive into the features that make Codux a game-changer for React developers. The session will include hands-on exercises that demonstrate the power of real-time rendering, visual code manipulation, and component isolation all in your source code.
Table of the contents: - Download & Setup: Getting Codux Ready for the Workshop- Project Picker: Cloning and Installing a Demo Project- Introduction to Codux Core Concepts and Its UI- Exercise 1: Finding our Feet- Break- Exercise 2: Making Changes While Staying Effective- Exercise 3: Reusability and Edge Case Validation- Summary, Wrap-Up, and Q&A
React Summit 2022React Summit 2022
98 min
Crash Course into TypeScript for content from headless CMS
WorkshopFree
In this workshop, I’ll first show you how to create a new project in a headless CMS, fill it with data, and use the content in your project. Then, we’ll spend the rest of time in code, we will:- Generate strongly typed models and structure for the fetched content.- Use the content in components- Resolve content from rich text fields into React components- Touch on deployment pipelines and possibilities for discovering content-related issues before hitting production
You will learn:- How to work with content from headless CMS- How content model can be leveraged to generate TS types and what benefits it brings to your project- How not to use string literals for content in code anymore- How to do rich text resolution into React components- How to minimize or avoid content-related issues before hitting production