Getting Started with Redwood for Beginners

Episode Description

Anthony Campolo introduces RedwoodJS, a full-stack React framework with built-in Prisma, GraphQL, auth, testing, and powerful CLI generators.

Episode Summary

In this Teach Kelvin Your Thing session, Anthony Campolo walks through RedwoodJS, a full-stack JavaScript framework he credits with helping him land his first tech job. Anthony explains what sets Redwood apart from other frameworks like Next.js or Nuxt — namely its deep integration of Prisma for database management, GraphQL for mediating between front end and back end, and convention-over-configuration philosophy that bundles auth, testing, and Storybook support out of the box. He demonstrates the framework's powerful CLI generators, showing how a single command can scaffold pages, routes, cells for declarative data fetching, and full CRUD interfaces. The live demo covers creating a blog app from scratch, connecting it to a Railway-hosted Postgres database, and deploying to Vercel, complete with a classic live-demo hiccup along the way. Anthony and Kelvin draw parallels between Redwood and Kelvin's own custom full-stack setup using Sails.js, Vue, and Inertia, reinforcing the idea that developers have long craved this kind of integrated experience in the JavaScript ecosystem. The session closes with a look at the Redwood community, the upcoming V5 release candidate, and the Redwood Startup Fund backed by GitHub co-founder Tom Preston-Werner.

Chapters

00:00:00 - Introductions and Anthony's Redwood Origin Story

Kelvin welcomes Anthony Campolo to the show and asks him to share his background. Anthony explains that he first encountered RedwoodJS in 2020 while attending a coding bootcamp, got involved through writing and speaking about the framework, and eventually became a core team member. He credits Redwood with helping him break into tech professionally.

Anthony recounts how his bootcamp projects consistently failed to ship functional full-stack apps using Create React App, Express, and Postgres, but with Redwood he could build the same thing solo in a single day. This experience convinced him that Redwood's integrated approach to full-stack development was genuinely transformative, especially for beginners who would otherwise struggle to wire together authentication, databases, and deployment on their own.

00:05:01 - How Redwood Compares to Other Full-Stack Frameworks

Kelvin asks what technologies make up Redwood and how it stacks up against competitors. Anthony breaks down the core stack — a React front end, a Node backend, and GraphQL as the mediating layer — and highlights Prisma as the deeply integrated ORM that distinguishes Redwood from frameworks like Next, Nuxt, or SvelteKit, where you bring in database tools yourself.

Anthony argues that Redwood and Create T3 App are the only true full-stack JavaScript frameworks comparable to Rails or Laravel, since other popular options stop short of the database layer. He and Kelvin then discuss Kelvin's own custom full-stack setup using Sails.js, Vue, Inertia, and Tailwind, finding common ground in the desire for a single-codebase experience that handles both front end and back end concerns without duplication.

00:12:29 - Project Structure, CLI Generators, and Routing

Anthony begins the live demo by explaining Redwood's project structure, which separates code into a web side and an API side. He demonstrates the CLI's page generation command, creating home and about pages with a single terminal command, and walks through how Redwood's custom router uses named route functions to wire up paths, components, and links.

The discussion covers how Redwood's conventions provide guardrails — automatic file structure, consistent naming, and a routing file that cleanly maps paths to React components. Anthony also briefly touches on layouts for persistent UI shells like navigation bars, then shows how easy it is to toggle between pages using generated link components, emphasizing the developer experience benefits of having all this scaffolded automatically.

00:18:30 - Routing Deep Dive, SPA vs. MPA, and the Vite Migration

Kelvin asks whether Redwood uses React Router, and Anthony explains it has its own custom router built from the ground up, with decoupled web and API packages that can function independently. They discuss how Redwood supports single-page apps by default but can pre-render pages into a multi-page app using a simple keyword, though runtime SSR is not yet available.

Anthony reveals that Redwood still runs on Webpack, having been started in 2018 before Vite existed, but a migration to Vite is underway and will unlock SSR capabilities. Both hosts share a lighthearted moment acknowledging that Webpack still works reliably, and Kelvin notes his own stack also remains on Webpack, before they transition into the database portion of the demo.

00:23:57 - Database Setup with Prisma and Railway

Anthony introduces the database layer by explaining Prisma's role as an ORM that generates SQL for whatever database flavor you choose — Postgres, MySQL, SQLite, or even MongoDB. He walks through creating a simple blog post model with fields for ID, title, body, and creation timestamp, then connects the project to a Railway-hosted Postgres database using a connection string in the environment file.

After running the migration command, Anthony shows the generated SQL and demonstrates how Prisma manages differences between database dialects transparently. He highlights Railway's developer-friendly approach, noting you can spin up a Postgres instance without even creating an account, and explains that the migration folder gives developers a learning opportunity to see the actual SQL being generated behind the scenes.

00:30:35 - Scaffolding CRUD and Building Cells for Data Fetching

Anthony runs Redwood's scaffold command to instantly generate a full CRUD interface for blog posts, complete with create, edit, and delete functionality connected to the Railway database. He then builds an articles cell from scratch to demonstrate Redwood's declarative data fetching pattern, where a single component automatically handles loading, empty, error, and success states without any manual conditional logic.

The cell concept is one of Redwood's most distinctive features, and Anthony shows how importing a cell into a page immediately gives you a working data display with built-in error handling. He modifies the cell's GraphQL query and success template to render blog posts with proper HTML markup, illustrating how cells eliminate the repetitive boilerplate of managing fetch states that developers typically write by hand in React applications.

00:38:40 - Testing Infrastructure and Storybook Integration

Anthony demonstrates that every page and cell generated by Redwood's CLI comes with pre-written test files using Jest and React Testing Library, ensuring baseline test coverage even if developers don't write additional tests themselves. He runs the full test suite with a single command and explains that Cypress is also available for end-to-end testing, while Kelvin mentions his own preference for Playwright.

The conversation moves to Storybook, which Anthony describes as transformative for component development. He shows how Redwood automatically generates story files alongside every component, letting developers visually inspect all possible states of a cell — loading, empty, failure, and success — without needing to manipulate network conditions or mock data manually. Anthony recalls his own first experience with Storybook through Redwood as a revelatory moment in his development workflow.

00:44:42 - Authentication Options and Deployment to Vercel

Kelvin asks about Redwood's built-in authentication, and Anthony explains the framework supports multiple providers including DB Auth, Clerk, Firebase, Netlify Auth, and Supabase, directing viewers to a recent deep-dive stream for detailed implementation guidance. He then moves to deployment, showcasing Redwood's support for numerous hosting platforms including bare metal servers, Netlify, Vercel, and his own company Edgio.

The live deployment to Vercel encounters a classic demo-day database sync issue, which Anthony troubleshoots in real time before successfully getting the project online. Despite the hiccup, the process illustrates how straightforward deployment is once the project is connected to a Git repository and the database environment variable is configured, reinforcing the framework's goal of making the entire development-to-production pipeline as smooth as possible.

00:49:58 - Community, Redwood V5, Startup Fund, and Closing

Kelvin summarizes his key takeaways — Redwood's strength lies in orchestrating all the pieces of full-stack development into a cohesive, convention-driven experience with generators, testing, and deployment built in. Anthony addresses the common GraphQL hesitation, arguing that Redwood was specifically designed to simplify GraphQL development alongside the broader full-stack workflow.

Anthony highlights the Redwood community resources including the Discord, forum, and monthly town halls streamed on YouTube. He shares news about the V5 release candidate bringing React 18, background jobs, and cron support, and mentions the Redwood Startup Fund backed by GitHub co-founder Tom Preston-Werner, which includes a special focus on climate tech startups. The session wraps with Anthony plugging his podcast FSJam and his company Edgio's upcoming improved Redwood support.

Transcript

00:00:00 - Kelvin Omereshone

Hey there, everyone. Welcome to yet another Teach Kelvin Your Thing session. In today's session, I will be learning Redwood with Anthony. So how are you doing, Anthony?

00:00:19 - Anthony Campolo

Hey, what's up? I'm doing good. Thank you so much for having me.

00:00:23 - Kelvin Omereshone

Yeah, I'm really excited because I think I heard about Redwood a couple of years ago, and I've been interested and really looking out for someone who's gonna be available to come on the show to teach me Redwood because it really sounded interesting. So before we go into Redwood land, or the woods, could you please introduce yourself, tell us who Anthony is, what you do, what you've been doing, and just anything you want to share?

00:00:54 - Anthony Campolo

Yeah, sure thing. So my name is Anthony Campolo. I am a developer advocate at Edgio, which is a deployment platform. And I've been interested in Redwood and working on it for quite a while, actually. I first got into the framework back in 2020, when it was first announced. I was actually a bootcamp student at the time and was trying to get into web dev, and I was interested in open source and saw that there were a lot of these different frameworks coming out, especially in the React world, which is what I was learning in my bootcamp. I just kind of started writing about it, then speaking about it, and then eventually going to meetups and getting to know the team. And yeah, they eventually invited me on as a core member in late 2020, and I got my first dev job a couple of months after that. The two were actually very closely correlated. I kind of credit Redwood with getting me my first job in tech. So it's a really great community. It's welcoming to beginners, and if you're an expert, it's also good.

00:02:00 - Anthony Campolo

We say it's an app framework for startups. We really pitch it as something for building companies and, you know, really using it for serious production workloads. So really happy to kind of explain it and talk about what it is.

00:02:17 - Kelvin Omereshone

Yeah, for sure. So the question I have right now is: what about Redwood really got you like, "Whoa, this is..."? And I feel you, because you mentioned you'd not used any other framework before you used Redwood. Is that true?

00:02:37 - Anthony Campolo

I wouldn't say I hadn't used any other framework. It kind of depends, you know, the whole question of what is a framework. I'd used Create React App.

00:02:44 - Kelvin Omereshone

Okay.

00:02:45 - Anthony Campolo

I'd used Gatsby to kind of generate a blog starter. I had used Next just very sparingly at the time, and I kind of played around with a little bit of Svelte and Vue stuff. But to answer your question, what made Redwood different? The thing that made Redwood different, really, is that it was, to me, a full-stack framework. Because at the time when I was doing my bootcamp, we were building a full-stack React project using Create React App hooked up to an Express server that then would hit a Postgres database, and you'd use Axios and kind of manage the auth and the backend server. Creating that whole project, that whole workflow, was very challenging, to the point where we had these build weeks where people who were at every different point within their bootcamp journey would have to get together and build an actual app that would function and run, that a user could log in to and just do something. It could be just like save a bookmark or something like that.

00:03:53 - Anthony Campolo

But I did four of those, and all four of those projects did not actually ship in a functional form to the point where a user could log in and do the base functionality. And I thought that was kind of incredible, because it was both really a failing of the bootcamp that they couldn't actually set us up for success, but also a failing of the tech stack to make it so challenging to even make a functioning app. It really shocked me. And when I then used Redwood, I saw that you could basically generate a whole project that already had the backend, already had a database, and already had an authentication solution. And you could run a command that would set up your auth, and you could run a command that would deploy your project. And I found that in one day I could build the same project by myself that the group could not build in a week. And so that's when I realized there was really something unique happening here. And this is actually a tool that would be very beneficial to beginners. Despite the seeming complexity of the whole thing and all the different tools and cutting-edge tech, I actually found it incredibly simple to use.

00:05:01 - Kelvin Omereshone

I feel that makes a lot of sense, because I like a tool that lets you move fast, right? So from what you're explaining right now, it feels as though Redwood sort of takes care of the table stakes, the things you would normally need for your app, and just gives you a push. You've actually covered more ground by just making the app. You have authentication, which is something most apps would need, so you should not have to write that all the time yourself, right? So Redwood's just going to do that. That makes a whole lot of sense. So in a nutshell, how does Redwood compare with other full-stack frameworks out there? What's in Redwood, for example? What makes up all the technologies it puts together to make up Redwood?

00:06:00 - Anthony Campolo

Yeah, the main thing, to kind of break it down to its core, is that Redwood is really a React front end and a Node backend. And the thing that is most important is that it uses GraphQL to mediate between the front end and backend. So you need to know a little bit of GraphQL to use it, but not a lot, because when I first used the framework, I had never used GraphQL at all. But the thing that separates it, I think, from other frameworks like Next or Nuxt or SvelteKit is the ORM layer. So a lot of people will use Prisma with those frameworks, but you're usually bringing in Prisma separately as its own dependency. You'll install it, then you'll kind of write a Prisma schema, and then you'll create your backend kind of like service logic, and you'll do all that from scratch. Whereas with Redwood, you already have Prisma actually embedded within the CLI, so you can run Redwood commands that are kind of aliasing Prisma commands, and you already have generator commands that will write a lot of your Prisma logic for you. And then there's also the built-in auth provider, as I mentioned, which allows you to kind of hook into other things.

00:07:14 - Anthony Campolo

And now, you know, you have things like NextAuth or third parties like Clerk that make it pretty easy to integrate that into things like Next, Nuxt, or SvelteKit. But it's still like Prisma, where you're installing a different dependency and wiring it up yourself. Whereas with Redwood, there's convention. So the main thing is convention over configuration, I would say. Today, the framework I find most comparable to it is called Create T3 App, which was kind of created by Nexel and Julius and a lot of the community around Theo. So if you know who Theo is and you know that community, you know all those people and kind of what's going on. If not, you might not be super hip to it, but it's basically Next.js plus the extra stuff that Redwood gives you. So it also has Prisma already auto-configured, it has an auth provider auto-configured, and I find that's kind of the most comparable full-stack JavaScript framework around right now. But with things like Nuxt, Next, Remix, SvelteKit, SolidStart, and Qwik City, all of those kind of take you all the way to the database layer and then drop you off there and say you can figure out how to connect your database.

00:08:25 - Anthony Campolo

They'll give you serverless functions, and so people will say that they're full-stack frameworks, or some people even say they're backend frameworks. But to me, Redwood and Create T3 App are the only real, true full-stack JavaScript frameworks, if you're using that term in relation to things like Rails and Laravel and Django.

00:08:47 - Kelvin Omereshone

Interesting. That's a strong claim. I like it. Yeah, so I get the point where, with something like Next or Nuxt, I think they're more focused on the client than on a complete, robust app that needs access to the database and needs to manage your schemas and all. If you need to do that, then you're probably going to do serverless or you need a separate backend. But with what you're saying now, you can have everything in one place with Redwood, and it all pieces nicely together. So yeah, that sounds fun. I am intrigued enough to want to start seeing the code and how the DX plays, because I'm a big Sails.js guy. For the full stack, I made a stack called the Vite Stack, which is Vue, Inertia, Tailwind, and Sails. It really plays well for me, where Vue is on my front end and Sails takes care of all the MVC stuff. We have an ORM and everything. So that is kind of my true north.

00:09:53 - Anthony Campolo

Cool, so you already built a version of this then?

00:09:58 - Kelvin Omereshone

Yeah, I think that would be a year ago. So it uses something called Inertia. Inertia is like a protocol that lets you use Svelte, React, or Vue. You can mix them with your backend, but those components are going to be your front end, and all the routes will be handled with your backend. The database access and everything is there. I just love the stack. But let's see Redwood and the DX and everything. Are you ready to get into it?

00:10:29 - Anthony Campolo

Yeah. And just to kind of piggyback on what you said, that's really interesting because it's true that a lot of people will build things like this. This is something one of my... I have a podcast, FSJam, which is Full Stack Jamstack, and the idea is that it's like full Jamstack plus the backend to give you the full stack. And my co-host Chris used to always say we were all building Redwood before Redwood because he felt that he had already created this stack and then he saw a framework that had actually done it. That's a similar thing with what you're talking about. You kind of created your own framework that added in that backend layer using Laravel, which is a project I haven't used yet, but I've heard of and think is very interesting.

00:11:14 - Kelvin Omereshone

Yeah, so my stack is JavaScript from top to bottom. It uses Sails. Sails is an MVC framework akin to Laravel, so it does server-side templating using EJS. But, being a Vue guy, I wanted a way where I could build a single-page application. So this was the use case for me. Before, I had a platform, salesguys.com, where the front end was a Nuxt app and the backend was a Sails API. But I felt there was no need for this. So I was thinking: is there a way to have a single-page application and everything still be in the same codebase, and I use my backend logic, my backend policy, my backend middleware, my backend routes, instead of duplicating it across the stack? And that was where I found Inertia, which came out of the Laravel ecosystem and let you do this. Then I wrote an adapter for Sails and, of course, I like Tailwind, and it created a Vite Stack. So I made a stack that I feel pretty comfortable shipping, and yeah, that's what the Vite Stack is in a nutshell.

00:12:18 - Anthony Campolo

That's cool. That's really cool. Yeah, we can get into the code now.

00:12:22 - Kelvin Omereshone

Definitely. Let's do it.

00:12:29 - Anthony Campolo

All right, so I'm going to be kind of following along with this gist here, just to kind of go over the outline real quick. What's great about Redwood is it has a CLI that can generate a lot for you. So we can generate pages, we can create database migrations, we can create what are called cells. That's for data fetching. I'll explain that once we get to it. And then you can also run tests and set up Storybook with just a single command. So we'll show a little bit of that. One of my core team members on the Redwood team was saying that we should really show off the testing and Storybook capabilities. And then we have the deploy step. We'll deploy it to Vercel. But just to kind of start by showing a bit of the project structure, we have these two main what are called sides. There's the web side and then there's the API side. So the first thing we'll do is just kick off our dev server. So all of the commands are going to start with yarn rw and then the command that follows. So this is the Redwood splash page that you'll see when you first kick off your dev server with a new blank project.

00:13:52 - Anthony Campolo

So it gives you some links to tutorials and docs and the community, if you want to check it out. We've got a Discord, a forum, and a Twitter account, so I highly recommend you check those out. And if we look at our web folder, we have three things here. We have components, layouts, and pages. Now, if we look in the pages folder, we're not actually going to see this, because this is just a placeholder until you do actually generate your first page. For the command to do that, all of our commands, as I mentioned, will start with yarn rw and then a generate command, which you can shorten to g, and then the thing you're going to generate. So we're generating a page right now, and we're going to call it the home page, and it's going to go to our home route. So if this was on ajcwebdev.com, this would just be ajcwebdev.com/. And if we create that, we're going to see here that we're now going to have a home page. And this is the standard boilerplate. If we look at it here, this is where it takes the word we inserted and puts it in all these places.

00:15:12 - Anthony Campolo

And this here gives us an example of a link as well. So let's look at this file over here. If we want to edit this, we can change this to just say, "Hello, world." And then now we've got our home page. Now you may be wondering how the routing layer is working, and to figure that out, we have this routes file. And what the routes file does is it specifies three things for each page. You have a path, which is what the actual route is. You have the page, which is the React component that you're pointing to. And then you have what's called a named route function. The named route function is how you link to it with your a tag or Link tag. So if we look here, there's this link to and then routes.home, and the home is the function that will take you to the home link. So to show a little more clearly what's happening here, let's generate another page. And if we look at what happens with this file, we can kind of see. So here again, yarn redwood generate page about, and then we don't have to specify anything afterwards if we want the route and the named route to be the same.

00:16:41 - Anthony Campolo

So it's just going to take "about" and insert it into both. So now we've got our about path, our about page component, and our named route function. Over here we can see we now have an about page and, again, all the places that "about" was generated into. So you can see how the conventions here are giving you nice guardrails in terms of already giving you file structure, giving you conventions for how your pages are going to be mapped to the router, and then giving you kind of nice functions that allow you to create links that don't need to be changed anytime you want to make a change. Like, if I want to point the about page to a different page, then I can just change that in the route file and point it at a different page, but then all the links will stay the same. So that's pretty nice. If we just change this to say, "Page tells you about stuff," we've got our about page right now. Now, at this point, for the tutorial, you would usually then go into layouts, but those are not really that interesting.

00:17:56 - Anthony Campolo

And just for the sake of time and showing other features, I'm going to kind of skip over that. The point of a layout is just to give you a persistent shell that can persist between different pages. So if you want to have a nav bar, then you can put that in your layout, and then that will wrap around all your pages. But right now I'm just going to have these two links right here, which will let us toggle back and forth between our about page and our homepage. So do you have any questions so far based on all of that?

00:18:30 - Kelvin Omereshone

Yeah, a couple. One is: is Redwood wrapping React Router, or is it its own custom router?

00:18:40 - Anthony Campolo

It's its own custom router. So that is a really important part of what made Redwood unique when it first came out, is that it wasn't using React Router and it wasn't using Next kind of as a front end to bolt a backend onto. It was all made from the beginning. So that's why this routing file here, the way it's set up, you won't see this in any other framework. And you see here we're actually importing the router package from the RedwoodJS main package. So there's a RedwoodJS npm repo that then links to all these other packages. So if we look in our package.json, we'll see our front end has Redwood Web, Redwood Router, and then Redwood Forms. And in our API, which we'll look at in the next section, we have the Redwood API and then the Redwood GraphQL server. So all of those packages kind of make up your project. And this is where you actually have a decoupled kind of thing going on here. This is not a monolithic thing in the sense that you install one thing that has a hundred packages in it.

00:19:50 - Anthony Campolo

You can actually kind of break this apart. And if I wanted to entirely delete my web folder and then just have a standalone API, I could do that, or vice versa if I wanted to delete the API. Just have a standalone static front end. You can also do that.

00:20:06 - Kelvin Omereshone

Cool. So yeah, that's sort of like two separate packages or how do I say this? So it's like an API with its own package.json, so that's standalone, and the web with its own package.json, so that's also standalone. So they are not sharing dependencies or anything. They're just in the same code base. The other thing I was going to ask, but I think it's obvious now, the UI is a single-page application, right?

00:20:39 - Anthony Campolo

So it is by default. If you want to, you are able to actually make it a multi-page app by using a pre-render keyword. So you can do something like that. If I did that, it can actually pre-render just an HTML shell with the about page in it, as long as there's no interactivity. So this is one of the things that I thought was actually really innovative, and something that now everyone was talking about: how do you create these frameworks that can kind of transition between a SPA or an MPA? And there are already conventions in Redwood that allow you to just generate brand-new pages on the fly, and you can start and make it entirely a multi-page application. I could pre-render each of these pages, and then it would just ship as multiple pages. Or I can build up a single-page application and just build the entire app on the homepage. It's really entirely up to you.

00:21:30 - Kelvin Omereshone

That totally makes sense. So the pre-rendering is sort of SSR, right?

00:21:37 - Anthony Campolo

Yes, it's SSR at build time, not at runtime.

00:21:40 - Kelvin Omereshone

Oh, so that's the one thing that...

00:21:43 - Anthony Campolo

That's the one thing that Redwood is kind of missing right now, is that there's no way to do SSR at runtime. But we're going to be there very soon, because we're integrating Vite, and then Vite is going to kind of come along with all that SSR goodness.

00:21:57 - Kelvin Omereshone

Yeah. So right now it's more of SSG, akin to Astro, if you're doing the rendering attributes right. It's like an...

00:22:07 - Anthony Campolo

SSG, or just a straight-up client-side-rendered kind of deal, or a multi-page application. So it basically does everything except SSR in the Next.js kind of sense. Right now, that's the main thing. But aside from that, you can do single-page app, multi-page app, you can pre-render pages, you can do a totally static build, you can bring in kind of whatever you want.

00:22:31 - Kelvin Omereshone

Oh, so I noticed you mentioned Vite is coming to Redwood. So what are you running on right now?

00:22:40 - Anthony Campolo

Good old Webpack. This framework was first started being worked on in 2018, and then the 0.1 came out in 2020, and Vite hadn't even come out yet. Vite came out in 2020. So it's been a long journey to kind of rewire it from Webpack to Vite. And that's kind of why it's taken us multiple years to get to the point where we're going to be able to flip that switch. And yeah, I'm really excited about it, because I think we're, aside from Next, probably the only non-Vite framework around anymore.

00:23:21 - Kelvin Omereshone

Yeah, it's a good thing you mentioned it. We're still on Webpack for the stuff I talked about. Still thinking of it because, you know, that's where everyone is right now. But yeah, Webpack still works, huh? It's like you wouldn't even notice.

00:23:38 - Anthony Campolo

Yeah, it does. I mean, and there are companies that are going to be running Webpack till you and I are both long gone. I'm willing to bet.

00:23:45 - Kelvin Omereshone

Definitely. Yeah, Webpack is cool. So, sure, those were my questions. Let me let you go on with the database. I love databases.

00:23:57 - Anthony Campolo

Yeah. Let me real quick... I have this one kicking around from the last time I did this. Let me just delete this real quick. Have you ever used Railway?

00:24:08 - Kelvin Omereshone

No, I've been a Render guy.

00:24:13 - Anthony Campolo

Cool. Yeah, so Railway is a very cool backend as a service, and it lets you spin up Postgres databases really quickly and really easily. Before I do that, though, let me explain the Prisma stuff. Have you ever used Prisma before?

00:24:32 - Kelvin Omereshone

No, I've seen it used. I used another one called Waterline, so yeah, but I get the gist. Yeah, Waterline from Sails.

00:24:44 - Anthony Campolo

Prisma's gonna change your life. It's really where I think the JavaScript ORM world has gone. It may already start to become unhip in a year or so as things like Drizzle and Kysely start to become more popular. But as of now, Prisma is the ORM to use. I think most people would probably agree with that. The one drawback it has is if you're running in a serverless environment, you can have pretty bad cold starts because of the bundle size, but they have products kind of aimed around addressing that with edge stuff. But if you're just doing a simple demo project, or if you want to get the perf of running on a server, you can do that as well. But let me just real quick break down what's happening here. The great thing with Prisma is that you can decide what flavor of SQL, or even non-SQL, you want to use. Right now we're going to be running Postgres, but I could change this to just say MySQL or SQLite or even, God forbid, MongoDB. And the thing that it does is it takes your model and then generates the SQL to make it work with whatever flavor of SQL you're using.

00:26:00 - Anthony Campolo

So if you're using Postgres or MySQL, there'll be slightly different SQL generated, but from the perspective of your app, your model remains unchanged for the most part. If you're switching from SQL to Mongo, that might not necessarily be the case, but if you're switching between SQL databases, you should be good. I would recommend, for the most part, just deciding on your database in the beginning and not switching. But if you want to live dangerously and migrate from SQLite to Postgres halfway through building your project, you technically can do that. You just have to blow away your migrations. But the model is just going to be a simple post. We're making a blog here, and a blog is not necessarily the best example for something you'd actually want to build with Redwood. It's more just kind of an exercise to help you understand the framework. You're really going to be using this more so for real-time kind of functionality. But just for the sake of what we're doing here, this is a good way to conceptualize the project end to end. And the blog post will have an ID, title, body, and createdAt. The ID is an integer, and it has an auto-incrementing function here.

00:27:05 - Anthony Campolo

So each new post will be, you know, ID 1, ID 2, ID 3. You could change this to UUIDs or something like that if you would prefer. And then the title and body both have a string, and then createdAt will take a date-time and generate it based on what time it is when the blog post is created. So does this kind of all make sense?

00:27:30 - Kelvin Omereshone

Looks neat with the decorators and stuff, but the conventions are the same thing we use in Waterline, and everything makes sense. So cool.

00:27:41 - Anthony Campolo

Great, I'm gonna run some commands here with the Railway CLI. This is going to initialize a project and then slap Postgres on the end. One of the things I do like about Railway is that you can spin up projects extremely quickly, and if you so desire, you actually can do this without even creating an account. If you just go to railway.app/new, if I was logged out right now, I could still generate a Postgres database and get a connection string. It would just be wiped in one week if I don't claim it with an account. But you actually don't even need a Railway account to do what I'm showing you right now.

00:28:23 - Kelvin Omereshone

Yeah, that's cool. So you also deploy your backend on the servers, right? Not just databases.

00:28:33 - Anthony Campolo

So the backend can be done in two ways. I'll just mention this briefly, and we can talk about it more in the deploy step. You can deploy it to a serverless kind of function backend through a service like Netlify or Vercel, or you can run it on a literal server, like on AWS or Flight Control or something like that. So you will run your backend somewhere. Whether you want to manage a server or not will kind of depend on the needs of your specific app, and whether you're concerned about cold starts with your Lambda functions.

00:29:07 - Kelvin Omereshone

Got it.

00:29:08 - Anthony Campolo

Yeah. So with the Railway backend, you'll have a connection string you can grab right here. And all you need to do with that is put it in your .env file. And you're going to want to have, for us, we don't need two databases just because it's a simple demo, but you can have a test database and then an actual production database. We're going to set both of these to the same database right now. And then once you do that, we'll run this command to create our migrations. So our migrations are going to live right here in our db folder. And the cool thing here is that you'll actually be able to see the exact SQL that's going to be generated and used to apply to your database. So if you're someone who is not super experienced writing SQL, you can actually kind of learn a little bit on the fly as you're going. So if you wanted to set up a database table yourself, this is the SQL you could run to do it: create a table, post, ID, title, body, createdAt. And as I was saying, this will look slightly different if we were doing this with MySQL or SQLite, but Prisma manages the differences through the migration commands.

00:30:32 - Kelvin Omereshone

Nice.

00:30:35 - Anthony Campolo

And then one other thing, just to kind of show what happened here. If we go back now, this is our database. So we can see we have a post table with no posts in it. And to create the posts, we can do this scaffold command. This is where the real magic of Redwood, in terms of getting set up really quickly and having an instant CRUD interface, comes in. So what this is going to do is generate a whole bunch of stuff. And before we even kind of look at all the code it generates, let's go back and see what our actual running project looks like. If we go to /posts, this is now our posts interface. And this is all created for you out of the box. And if we want to create a blog post, do that, and then now we have a blog post. And if we go back to our Railway database, we now see this blog post right here in the data. So this is like what you would get if you were using Django. They have kind of an admin interface, is what they used to call this.

00:31:57 - Anthony Campolo

And you can edit posts. And then you've got edit, you can delete posts, it'll ask you if you're sure you want to delete it. I'm going to create just a couple of these: post one, post two, and post three. And if we want to look at all the code that is doing this, we can take a look in our pages and our components. So the post page is what we're looking at here, and our post components have all this stuff. This is where we have some of the GraphQL things coming into play. Instead of kind of looking through all this code that was just generated, though, let's build up a cell from the ground up that will be a bit simpler to understand. Cells are really, really cool, and they're one of the unique things about Redwood that, when people try Redwood for the first time, seems to get them really hyped up. So as with all things in Redwood, we can run a command to create our cell. So our cell is going to be called articles: yarn redwood generate cell articles. And let's take a look over here. Now there's a couple things going on in a cell.

00:33:32 - Anthony Campolo

The important thing, though, is that there's your GraphQL query and then there are the different output states for your cell. So remind me, did you say you have or have not used GraphQL?

00:33:45 - Kelvin Omereshone

I have used GraphQL, but not heavily. I'm more of the REST guy.

00:33:51 - Anthony Campolo

Okay, cool. But you understand a GraphQL query, and this isn't totally incomprehensible to you?

00:33:58 - Kelvin Omereshone

Yeah, definitely. I did write some a week ago for an article I was writing, so I still understand it.

00:34:05 - Anthony Campolo

Great, that's awesome. So to make kind of clear what's going on here, I'm going to import this cell into the home page. So we see here we can import the articles cell and then plop it right here. So if we go back to our home page, we're going to see that. And that is because I need to change the name of it here, here, and here to actually do this. So if you look at it right now, our GraphQL query is just pulling in the ID of each post and displaying each post on the page here. Now if we were to just delete all these posts, and we had no posts at all, then we would see something different. We would see the message "Empty." Now this is because the cell itself knows how to display the correct state that it is in at any point in time. So you also noticed when I had the wrong name here, we get an error, so it's giving us our error automatically. We didn't have to write any error-handling code. And if it's empty, it lets us know it's empty. We don't have to write any empty code.

00:35:28 - Anthony Campolo

If we edit this here, we can change what our empty message is. Or if you want to change the error, you can break it, and then look at that, you can see your error message changes. If everything goes according to plan, though, and it works out and you have some posts, then the success state is what you want. And also, if I refresh, you can kind of see it's loading very, very quickly. And then the last one is the success state. So let's create some posts: post one, post two, and post three. When we have all those set up and the success is working, then we can bring in whatever we want from the post. You see the body, the title, and then the createdAt date. But the last thing we want to do is make it look a little nice, because right now it's just dumping a raw JSON object by JSON.stringify, which is a nice convention because it means that you're always going to get your data and be able to see it. But what you really want is a sweet little React component with some HTML. So if we look at this now, we are mapping over our posts, mapping over our articles, then setting the key to the ID, setting the title to an H2, setting the body to a paragraph, and then setting createdAt to a div.

00:36:59 - Anthony Campolo

So any questions about what's happening with the cell?

00:37:04 - Kelvin Omereshone

Yeah, it's fairly easy to understand. So we have the data source, which is GraphQL, a GraphQL query. Then we have UI states: loading, empty, failure, then success, which totally makes sense and maps well.

00:37:23 - Anthony Campolo

Yeah, I'm glad it makes sense because when you kind of hear it explained abstractly, we say that it's a way to make your data fetching declarative, which can be a little bit of confusing terminology. But once you see it, I think everyone has written this logic where you get the posts, you set the posts to the query, then you do the if-posts or if-!posts logic, then you get an error message, and then you end up writing this kind of conditional logic to handle whether it's loading, empty, or failure. And then you write your success logic. Whereas Redwood's like, you don't need to do that. You'll never need to do that at any point in time with Redwood, because it's all handled for you. This really saves you a lot of time if you're creating a project with a lot of data fetching. This is our end-to-end page now, or end-to-end project. To kind of get a little bit into the testing stuff, though, let's take a look at just some of the test files that have been generated already. If we look at our home page here, we can see that we have the kind of basic test.

00:38:40 - Anthony Campolo

The stuff we're using under the hood is most of your standard React Testing Library. We have Cypress in here, and we have basically any kind of basic test you want to do. I don't write a lot of tests, I'll be honest. I'm a DevRel. DevRels tend not to write a lot of tests. But Redwood really believes that testing is important and that you should have good testing infrastructure already set up for you. So here, this is going to make sure that at least, at baseline, your homepage renders and it renders correctly. So that's kind of your first basic test, just to make sure that you're testing all of your pages. And then for your cells, you're also going to be able to test those. So here we're already going to be testing all of the different states: whether the loading works successfully, whether the empty works successfully, the failure, and the success. So this is testing and verifying that each of your individual actual cell logic functions are all working as intended. And so every time you create a cell, every time you create a page, any of those things, they're always going to have a test already written for you that is at least a basic TDD-type setup, test-driven development.

00:40:01 - Anthony Campolo

So it ensures that if you are too lazy to write tests, there will at least be a test somewhere along the line that will make sure you're not going to shoot yourself in the foot. Let me kick that off. And if you want to actually run the tests, you do yarn rw test, and it's also going to actually test along with the database. This is why you want to make sure you have the test database set up, or else it's going to throw an error, because you don't want to run the actual tests on your production database. But here we're going to see our test suite and our tests. So we've got all of our tests passing right here. So that is maybe not super exciting, but if you're someone who is writing a project that's going to need a lot of tests, this will save you a ton of time. Any questions about that?

00:41:05 - Kelvin Omereshone

No, super fine. I think I know Jest just a bit. I've done some Jest before I switched to the testing framework I use, so...

00:41:18 - Anthony Campolo

I forgot to mention: it's using Jest under the hood, along with React Testing Library, and Cypress has got all those. So if you want to test your components, if you want to test just basic stuff with Jest, or if you want to run an end-to-end test with Cypress, those are all available to you.

00:41:34 - Kelvin Omereshone

That's amazing. Also, I'm aware of React Testing Library. I don't use Cypress, I use Playwright, but I do know how it maps, so it's really fine.

00:41:44 - Anthony Campolo

Yeah, really. Honestly, Cypress is more so what Redwood uses to test the Redwood framework. Cypress is pretty high-level. But you can also, if you want to actually test your Redwood app in an end-to-end manner, do that.

00:41:57 - Kelvin Omereshone

Cool, cool.

00:41:59 - Anthony Campolo

So before I deploy it, the last thing I want to show is Storybook. Have you ever used Storybook before?

00:42:06 - Kelvin Omereshone

Just once.

00:42:08 - Anthony Campolo

Just once, yeah. A good buddy of mine, Michael Chan, works for Storybook, and it's really great if you are going to be creating a lot of components, or if you have a lot of styling, or you're going to be building a really involved kind of cell. So if you see here, we've got these different states that your project can be in. But as I was showing here, when you're actually developing, it's kind of hard to just see that. If you're refreshing, you can see the loading spinner, or you can slow your network down to kind of see the loading, but that's kind of a lot of friction. It's a lot easier if you can just see all the different states your cell can be in, and you can kind of test them out. So you can see what your empty is, what your failure is, what your loading is. You can check out what your pages look like, and you can cycle between all of that. Now, one thing that I'm not going to show, because we probably won't have enough time, is that there's no actual data here.

00:43:08 - Anthony Campolo

That's because you are able to mock your data. So Redwood also has mocking built in as well. So if you want to mock your API calls, that's kind of one further step that you would do after this.

00:43:22 - Kelvin Omereshone

So this is generated alongside any time we make a Redwood page, right?

00:43:30 - Anthony Campolo

Yeah. Oh, and let me show that actually real quick. So when we create a homepage, it also creates... When you create any pages, you're getting three files. You're getting the component itself, you're getting a story file, and you're getting a test file. This is another thing. If you wanted to use Storybook yourself and you had to actually bring it into your project, you have to install that dependency. You have to create this file, you have to figure out how to import it, you have to figure out how to do this generate thing, you have to figure out what's happening here. And this is all Storybook conventions. That's overhead you have to learn to really get going. Whereas with this, all of this is generated out of the box with the CLI, and then you run a single command and your Storybook works. So I'd never used Storybook before Redwood. I remember the first time I ever used it with Redwood. The way I described it, I felt like Dorothy in The Wizard of Oz the first time she walks outside and everything's in color for the first time.

00:44:26 - Anthony Campolo

I'd been working through this super low-resolution way of creating my components through my dev server and having to make these hacks to see the different states it was in. And then I ran the Storybook command. I'm like, "Oh, here it is. It's everything. The whole world is in front of me now."

00:44:42 - Kelvin Omereshone

Interesting. So there's just this part that I think we could wrap up with, because I just want to see how it works. We did speak earlier on about Redwood having stuff like authentication out of the box. Could we see a little bit of that, and a little bit of authorization where, you know, you're logged in before you can make a post? Just something like that, just to see how that works.

00:45:14 - Anthony Campolo

That's a good question. So kind of the problem with making this simple is that there are many ways to do auth, and I have not used any of them in a while. So you can kind of self-host it yourself through DB Auth. You can connect Clerk, you can connect Firebase, you can connect Netlify Auth. There's also a Supabase integration now. So it was not part of the things that I had prepared for this demo. But I would recommend, for people who want to learn more about Redwood auth, there's a really great resource. This one's a little old, so that might not actually be the best video, but I did a stream with Dom recently where we kind of walked through the newest auth framework. So if you just search RedwoodJS Auth, you'll find this video with Nick Taylor and Dom. Dom actually gives a deep dive into the current state of Redwood auth and shows how you can even build your own custom auth provider if you want. So I would direct people to that, because that would probably take a little bit more time than we have right now to add into the demo.

00:46:30 - Kelvin Omereshone

Cool. Yeah, that's actually totally fine. I love the fact that there are so many options.

00:46:38 - Anthony Campolo

And that's why I'm like, I know that each of them have their own little weird idiosyncrasies that I have not kind of stayed hip to. So I know if I actually pick any of them right now, I'm going to get tripped up by something.

00:46:49 - Kelvin Omereshone

All right, let's deploy.

00:46:52 - Anthony Campolo

Yeah. So the last thing is the deploy step, and this is where you really get a lot of the power, because as I was showing with all the different auth providers, it's the same thing with deployment providers. We have an embarrassment of riches in terms of choices. So if you check out the deployment page here, we have options for bare metal, which is just running it on an Amazon EC2. You can run it on Flight Control, which is kind of a wrapper around AWS. This is now known as Edgio. Actually, this is no longer Layer0. We need to update this page, but that's my company. And then we've got Netlify, Render, as you had mentioned. This might be getting deprecated, actually, so don't use that. Then Vercel. These are most of the deployment providers that most people are familiar with these days. Let me just go ahead and get this on a Git repo, because we have all these things already set up. It's very easy to just get it running. So here's the repo that I just created, and then all we've got to do is create a new project in Vercel and grab this, and then, yeah, make sure to include your database URL so it's able to connect to that, and then throw that in there.

00:48:34 - Anthony Campolo

And that's good. Now then, this will probably take a couple of minutes to deploy. So if you have final wrap-up questions for me as this is deploying, now would be a good time.

00:48:47 - Kelvin Omereshone

Yeah. I think the key takeaway of Redwood is the mastery in orchestrating all these pieces together to give you a full-stack experience. And of course, a big one is the generators that just generate your pages and everything you need, the Storybook, the tests, and all. And yeah, so I feel it's like you said: conventions, right? The convention is good. I could just keep saying why we would always need a full-stack framework, as opposed to trying to piece things together with something like maybe Next or Nuxt, where they are good for what they do, but at the end of the day, if you're going to build a full-stack application, you're going to need auth, you're going to need a lot of stuff, you're going to need tests. Most people ignore tests, but having a framework that really pushes you to test, or gives you the base level of testing, is great. And yeah, so I feel Redwood is checking all those boxes for me. It's really, really nice.

00:49:58 - Anthony Campolo

Yeah.

00:49:59 - Kelvin Omereshone

Oh, uh-oh. Whoa.

00:50:02 - Anthony Campolo

What's happening here? I probably should not have refreshed that. Okay, let that just run again. But yeah, I think you definitely got the idea and what makes Redwood really unique and awesome. And, you know, I'll see this on Twitter, a lot of people kind of complaining about how there are no full-stack frameworks in JavaScript that have all the conventions built in. I'll be like, "Have you checked out Redwood?" And the biggest kind of barrier for a lot of people seems to really be GraphQL, that either people don't know GraphQL or they've used GraphQL in the past and felt like it had a lot of overhead. So what I really try to stress to people is that if you have used GraphQL in the past and you thought it was really confusing and had a lot of overhead, and your project felt really complex, Redwood addresses those concerns. The things that make people feel like GraphQL is too complicated are one of the main things that Redwood was built for. It's not just built to simplify JavaScript full-stack development, it's also built to simplify GraphQL development.

00:51:21 - Anthony Campolo

And really kind of getting both of those things to play well together is the thing to do. I don't know why this is not working. That's not usually the problem.

00:51:35 - Kelvin Omereshone

So something about database schema empty? Something with the Railway database?

00:51:43 - Anthony Campolo

Oh, that's interesting. I think... not sure. Somehow I got out of sync with these databases. Here, let me do this. Let me grab this database URL and make sure that is what I'm actually doing here with this environment variable. So is that the same thing? Looks like it's the same thing. Let me go back to my project real quick. Oh, I think I know. I think I might be... Let me try here. That should be all good. Let me just run this. This is the first time I've had issues with deploying it in a very, very long time. So it's the demo...

00:53:12 - Kelvin Omereshone

It's because you're demoing Anthony.

00:53:14 - Anthony Campolo

It's true. The demo gods decided to smite me today.

00:53:20 - Kelvin Omereshone

Yeah, that's just the only reason.

00:53:25 - Anthony Campolo

Let's go back here and see what we've got cooking. Okay, let me do this. Test one, save. So that should all be fine. Let me try this one more time. If it doesn't work, I will have to call Guillermo Rauch and chew him out personally. So let me just wipe this and start over from scratch. And then also, to kind of mention some things that you could build with Redwood, I would point people to Everfund. This is one of the kind of flagship apps built with it. This is my co-host on my podcast, Christopher Burns. So that's a really great project that I recommend people check out. This looks like it should be doing fine.

00:54:49 - Kelvin Omereshone

Yeah, we are back in business.

00:54:57 - Anthony Campolo

We'll see how that goes now. Cool. The other couple of things to talk about are the community. As I mentioned, we have a Discord, we have a forum at community.redwoodjs.com. We have a V5 release candidate coming out. This is going to include React 18, background jobs, and cron. Really exciting stuff here. This is going to set us up to hopefully eventually end up in this brand-new React Server Components world. We won't be there entirely fully yet, but just upgrading to React 18 will kind of set us up for that area. And we do these monthly town halls that we really recommend people come and check out. We stream them on YouTube and we run them through Luma. So if you want to check that out and hang out in the chat and meet some of the team members, you're welcome to do that. There's also the Redwood Startup Fund. So this is pretty cool. This is something that is specifically for startups who want to build with Redwood, because one of the creators of Redwood is Tom Preston-Werner. Tom Preston-Werner was the original CEO of GitHub. He is very well off financially and is able to invest in both the Redwood project and companies that are using Redwood.

00:56:27 - Anthony Campolo

There's also a specific climate-focused arm. So if you see here, if you're working on climate tech or things related to climate change, then you'll get even more special attention from the startup fund, because that's something that Tom believes in very strongly and wants to help promote. I see a green check. That means I did it. I do not need to yell at Guillermo Rauch anymore, thankfully.

00:56:55 - Kelvin Omereshone

Thank goodness.

00:56:56 - Anthony Campolo

So there we go. It works.

00:56:57 - Kelvin Omereshone

Yeah, it works.

00:56:58 - Anthony Campolo

Yeah, something happened there with the database. Not really sure where we messed up along the way, but this is the project, so we for sure made it.

00:57:07 - Kelvin Omereshone

Yeah, we made it. Thank you so much, Anthony. Finally I have been able to see Redwood in action, and I really love it.

00:57:18 - Anthony Campolo

Lived up to the hype.

00:57:20 - Kelvin Omereshone

Yeah, it really does. I think if you like React, if you have a little bit of React experience, and you like GraphQL, or even because we did not need to touch the GraphQL and we can just build our stuff with the generators and everything, it does make a lot of sense. So thank you. Any final words, plugs you want to plug in? Because you have license to plug, since you're a teacher on this show.

00:57:48 - Anthony Campolo

Just check out redwoodjs.com. Our Twitter is also @redwoodjs, and if you want to follow me, I am AJCWebDev on all places on the internet. My podcast is FSJam. We talked about Redwood a lot in the early days of the show. If you go back here, you can listen to Tom talk about the framework back in 2020, but we've kind of expanded out from there. We talk to lots of people in the community. You can find episodes about Astro, about Solid, about Qwik, all the good stuff. Even a tiny bit of Web3, if you find that interesting. Not a ton, though. Don't worry if you're offended by that. And the last thing would be just my company. I would definitely recommend Edgio as an awesome deployment platform. We're going to be upgrading our Redwood support in the next couple of weeks, so I'll be doing a lot more stuff kind of showing how to work with Redwood on my company's platform. And we run at scale, so if you need to run at scale, we are your place.

00:58:54 - Kelvin Omereshone

Awesome. Definitely going to check it out myself and yeah, thank you so much for your time, Anthony, and have a great day.

00:59:03 - Anthony Campolo

Yeah, thank you so much. Really appreciate the invite. I had a lot of fun.