Building Fullstack Jamstack Applications with RedwoodJS

Episode Description

Anthony Campolo demonstrates building and deploying a full-stack blog application using RedwoodJS, covering its architecture, generators, and deployment to Netlify and Heroku.

Episode Summary

Anthony Campolo walks through RedwoodJS, a full-stack serverless framework for the Jamstack, starting with its origins — created by GitHub co-founder Tom Preston-Werner and three collaborators who found it difficult to wire together modern web tools while building a language learning platform. He explains Redwood's architecture, which splits into a React-based web frontend and a GraphQL-powered API backend connected to a database through Prisma. The bulk of the session is a live coding demo where Anthony generates a new Redwood app, creates pages and layouts using the framework's CLI generators, defines a Post model in the Prisma schema, scaffolds a full CRUD interface, and builds a cell component to display blog posts on the homepage. He then walks through deployment, configuring Netlify for the frontend and Heroku Postgres for the database, showing how environment variables and connection pooling tie everything together. A brief Q&A covers how Redwood differs from Gatsby — primarily in its built-in backend and database support — as well as CMS integrations and the variety of deployment options available. The session illustrates how Redwood's conventions and generators dramatically reduce the boilerplate needed to go from zero to a deployed full-stack application.

Chapters

00:00:00 - Introduction to RedwoodJS and Its Origins

Anthony Campolo opens the session by introducing RedwoodJS as a full-stack serverless framework for the Jamstack, or more simply, a program for generating web applications quickly. He shares links to the demo repository and accompanying blog articles for attendees who want to follow along.

He then covers the origin story of Redwood, explaining that it was created by Tom Preston-Werner (a GitHub co-founder), Peter Pistorius, Rob Cameron, and David Price. The framework grew out of challenges the founders faced building Chatterbug, a language learning platform that required multiple clients and heavy GraphQL usage. The core team has since expanded to twelve members.

00:03:04 - Redwood Architecture: Frontend and Backend

Anthony walks through Redwood's architectural diagram, breaking it into two main parts: the web folder (frontend) containing React components, pages, layouts, and routing, and the API folder (backend) housing the database connection, GraphQL schema, and service logic. He explains how the CLI generator commands like yarn rw g page and yarn rw g layout scaffold these pieces automatically.

He introduces the concept of cells, a Redwood-specific pattern for data fetching that automatically handles loading, empty, error, and success states. This convention eliminates boilerplate that developers typically write themselves when querying data and rendering conditional UI, making it significantly easier to wire up frontend components to GraphQL queries.

00:07:01 - Backend Deep Dive: Prisma, GraphQL SDL, and Services

The presentation shifts to the backend, starting with the Prisma schema file where the database provider is defined (SQLite for development, Postgres for production) and models like Post are declared with fields for ID, title, body, and timestamps. Anthony explains how Prisma acts as a next-generation ORM that translates between JavaScript and SQL.

He then covers the GraphQL schema definition language, where types, queries, and mutations are declared, and the services layer where database operations like findMany and findOne are implemented using the Prisma client. Everything gets stitched into a single GraphQL handler deployed as a serverless function. Anthony emphasizes that while there is a lot of code, nearly all of it is auto-generated.

00:13:37 - Live Coding: Setting Up the Project and Creating Pages

Anthony begins the hands-on demo by initializing the generated Redwood app, setting up Git, pushing to GitHub, and starting the development server. He generates a homepage and an about page using the Redwood CLI, showing how each command creates the component along with Storybook and test files automatically.

He demonstrates hot reloading by editing the homepage content and watching it update instantly. He then generates a Blog layout with navigation links between the home and about pages, explaining how Redwood's named route functions work and how layouts wrap page content. He imports the layout into both pages to enable navigation across the site.

00:24:35 - Building the Blog: Schema, Scaffold, and Cells

With the frontend navigation in place, Anthony moves to the backend. He edits the Prisma schema to define a Post model, runs a database migration to create the necessary tables, and then uses the powerful scaffold generator to produce a complete CRUD interface for managing posts. He demonstrates creating, editing, and deleting blog posts through the scaffolded UI.

Next, he generates a cell component to fetch and display posts on the homepage, adjusting the GraphQL query to retrieve titles, bodies, and timestamps. He writes a small mapping component to render each post with proper HTML structure, transforming the raw data output into something that looks like a real blog.

00:33:23 - Deploying to Netlify and Heroku Postgres

Anthony generates a Netlify deployment configuration using another Redwood CLI command, which creates a netlify.toml file and adjusts API proxy paths. He switches the database provider from SQLite to Postgres in the Prisma schema, commits everything, and connects the GitHub repository to Netlify for continuous deployment.

He then creates a Heroku Postgres database, retrieves the connection string, and adds it as an environment variable in the Netlify dashboard along with a connection pooling parameter. After triggering a rebuild to pick up the new environment variables, the site goes live. He notes that all the services used — Netlify, Heroku, and GitHub — offer free tiers, making the entire stack accessible to anyone.

00:41:18 - Q&A: Gatsby Comparison, CMS Options, and Wrap-Up

The session opens to audience questions, starting with how RedwoodJS compares to Gatsby. Anthony explains that while both use React and GraphQL, Gatsby lacks built-in backend and database support, making it better suited for simpler static sites, whereas Redwood targets interactive applications with persistent data storage.

A follow-up question about CMS integration leads Anthony to mention that community members have experimented with Netlify CMS and Sanity, and that any CMS with GraphQL support should integrate smoothly. He shares his contact information and points attendees to the Redwood community forum and Discord for further engagement. The host wraps up by thanking Anthony and reminding attendees about an upcoming developer conference.

Transcript

00:00:00 - Host/moderator

And yes, the floor is all yours, Anthony. Thank you so much for joining us.

00:00:08 - Anthony Campolo

All right, thank you so much. Thank you for having me. It's really great to be here and share RedwoodJS with you. Let me go ahead and share my

00:00:18 - Anthony Campolo

screen.

00:00:21 - Anthony Campolo

Building Full-Stack Jamstack Applications with RedwoodJS. These are the resources, and this is the repo of the project we're going to build. If you go to this repo right now, it'll just be empty. If you add "test" after, you'll get the test run I'll be going off of as the script, if you want to follow along. There's also a series of articles you can check out at that link.

RedwoodJS is a full-stack serverless framework for the Jamstack. If you don't know what any of these terms mean, it can sound like a bunch of nonsense, so a simpler definition is: a program for generating web apps. The idea is that it makes it very easy to create a full application quickly and get it deployed to users quickly. That is the idea behind Redwood.

This was the original team of four creators: Tom Preston-Werner, who was one of the founders of GitHub, and Peter Pistorius. They were working together on a company called Chatterbug.

00:01:42 - Anthony Campolo

Chatterbug was a language learning platform they were building. They needed to support multiple clients — a mobile client and a web client — and they started getting really into GraphQL. They were trying to put all these pieces together to create an application and found it to be very difficult. So RedwoodJS takes the lessons from that experience and tries to build conventions around how to do this better.

They then brought in Rob Cameron and David Price. Rob Cameron wrote the tutorial, which is really fantastic — I recommend checking it out if you want to get into Redwood. David Price handles a lot of the community management and talks to people who reach out wanting to get involved. We now have a larger, expanded core team — currently twelve members. There are a lot of great people working on this right now.

This is the architectural diagram of Redwood, and if it's a little overwhelming to look at, that's fine.

00:03:04 - Anthony Campolo

It can take a little while to wrap your mind around. What you really want to look at is on the left, where it says "Redwood Codebase." You have the frontend and you have the backend. The frontend is your web folder — that box that says "web" — and it contains your whole frontend. If you're used to React and building React components, or something like Vue or Svelte or any of these frontend JavaScript frameworks, that's what the web folder is. The API, the backend, is where you connect to your database, where you have your GraphQL schema definition language, and where you write your business logic and services. There are a lot of terms there, but we'll break each of them down one by one and show some code as an example.

As I was saying, this is similar to what you'd get from Create React App, Gatsby, or Next, where you have an index.html and index.js —

00:04:18 - Anthony Campolo

a single-page app. You have pages and layouts. Pages are just components, and you have links and routes that you import from Redwood Router. There are also commands to generate these. If you look at the top where it says yarn rw g page home, that's the command to generate a page. We're going to use a lot of different generator commands on the command line to create a lot of this from scratch.

Then you have your layouts — for example, a nav bar to switch between your homepage and your about page. You have the layout, your pages are inside the layout, and your components are inside your pages. There's also a generate command for this. All generate commands start with yarn rw g — "rw" is short for Redwood and "g" is short for generate, saving you some typing — then you tell it what you want to generate.

00:05:44 - Anthony Campolo

Before, we generated a page; this time we're generating a layout. A cell is a newer concept that Redwood has introduced for data fetching. When you want to display your blog posts on the front page of your blog, you're saying: I want a query for all of the posts, and I want to get the ID of those posts. That's the query at the top. If you've never used GraphQL before, some of Redwood might be a little foreign to you — there's a lot of GraphQL in there. This is a GraphQL query. We're defining the query and naming it BlogPostsQuery. Inside is what the actual query is: asking for the posts and the ID of the posts.

If you look at the bottom, these are all the different states your data can be in while trying to display the posts. If it's still loading, it'll show a loading indicator. If you don't have any posts at all, it'll say it's empty. If there was an error while trying to get your posts, it'll show you the error.

00:07:01 - Anthony Campolo

If everything went fine, it'll show "success" and give you the posts. This is all set up and wired up for you out of the box. Normally you have to do this yourself — get the data, then write all these conditionals to handle loading, errors, and success states. It's really nice to have these conventions that just work out of the box.

That's the frontend. Now we're going to look at the backend. The backend is where we have our Prisma schema. Prisma is a tool that allows us to talk to our database. If you've ever used any sort of ORM like TypeORM, Sequelize, or Hibernate, it's kind of like that, but a next-generation ORM. Then you have your functions — if you've ever done serverless Lambda functions, that's what Redwood is set up to do.

00:08:09 - Anthony Campolo

Especially because Netlify has Netlify Functions and there's a lot of nice integration there. What we're looking at here is our schema.prisma file. It first defines our database: where it says datasource, we're setting the provider to SQLite. SQLite is a good database to use in development, and then you just flip that to postgres when you want a Postgres database in production, which is what we'll be doing in this project. Then you set the database URL to an environment variable called DATABASE_URL. You get that from Heroku Postgres and put it into your Netlify dashboard — or Vercel with a different database. All these services are converging around the ability to pass around environment variables. The generator block creates your Prisma client, which handles the translation between JavaScript and SQL. Then we're creating a Post model, which is what your blog post will be — it will have a title and a body.

00:09:33 - Anthony Campolo

Each time you create a new blog post, it's automatically given a new ID, starting at 1 and incrementing by 1. Then createdAt is set to a DateTime with the now() function, so it records the time the post was created.

Going back to GraphQL, which is a really big part of Redwood: this is your schema definition language, where you declare your types. The Post type mirrors our Prisma schema — we're setting id, title, body, and createdAt, and defining the type of each. The ID is an Int, title and body are both String, and createdAt is a DateTime. The posts query — with Post in brackets — returns an array of individual Post objects from the database.

00:10:55 - Anthony Campolo

The exclamation point means it can't be null. You can also query for an individual post by providing the post's ID — since each post has an ID when created, you can search for a post with that ID and it returns the post. On the right, that's how you define mutations, which is how you create, update, or delete posts. GraphQL isn't just for querying — you can use it to tell the database to create a post or update a post. You can do a lot with it.

The services layer is where you actually talk to the database. We import Prisma — that's the import db — and create functions that use Prisma commands. findMany gives you all the posts; findOne gives you one post by specifying its ID. On the right are the CRUD capabilities.

00:12:18 - Anthony Campolo

Create, update, and delete. This is where you import the Prisma client and set it to db. This is all set up out of the box and generated for you. There's a lot of code here, but you don't have to write any of it — I'm just giving you some context so you understand what the code is doing. This is where everything gets wired up into one GraphQL handler, which is what gets deployed as your serverless function. It stitches your schema, services, and database together into one big handler.

If that didn't make any sense, that's okay — this stuff makes a lot more sense when you actually build a project. So that's what we're going to do now. All I've done so far is created a Redwood app with yarn create redwood-app, then a period, then the project name rw-jamstack-opo.

00:13:37 - Anthony Campolo

That has created our project. I also created this repo, which we're going to use — it's just empty right now. And this other one is the test run that has the script of exactly what I'll be doing here.

00:14:02 - Anthony Campolo

Okay, good.

00:14:11 - Anthony Campolo

I'm going to cd into the directory and then open our editor.

00:14:33 - Host/moderator

Cool.

00:14:36 - Anthony Campolo

This will initialize our Git repository and add all the created files to our staging environment. Then we're going to do our first commit, set the branch to main, add the remote origin, and push the project. Now if we refresh the GitHub repo, we have our Redwood project — just a blank project generated from scratch. To start our development server, we type yarn redwood dev. This will start the dev server on localhost, which will be open over here.

00:15:59 - Anthony Campolo

Once that starts up,

00:16:04 - Anthony Campolo

it's going to give us a splash page that says hello and gives you some information on how to set up a route. We'll go over that, so don't worry about it. Here's our homepage — "Welcome to Redwood."

00:16:21 - Anthony Campolo

That's nice.

00:16:22 - Anthony Campolo

Now we're going to generate our homepage. We'll open a new terminal tab — leaving the other one running so the dev server keeps going — and we'll do our best to make this readable with a lot on screen.

00:16:46 - Anthony Campolo

That should be a little better.

00:16:50 - Anthony Campolo

The first command is yarn redwood generate. We want to generate a page and call it home, set to the home route. When you go to a website like www.google.com, there's just a slash — that's the homepage. This will create our homepage along with a test file and a Storybook file. Storybook is a tool for quickly developing your components in a visual way. Tests are for unit testing your components.

Now over in the browser, we're still at localhost but the splash page is gone and our homepage is here. It was created inside our web folder — we have our web folder and api folder as we discussed in the slides. Inside the web folder we have our src folder, which contains pages, layouts, components. Inside pages we have HomePage.

00:18:10 - Anthony Campolo

This is what we're looking at on the right: a component with an <h1> containing "HomePage," a paragraph with some text, and another paragraph. These are links, but right now they're just linking to the page itself, so clicking won't go anywhere. We're going to delete these links because we'll put them in our layout in a second.

00:18:43 - Anthony Campolo

Let's put: "Hello, Jamstack OPO."

00:18:52 - Anthony Campolo

Now if we save, it changes on the right. Our development environment is set up so every time you save a change in the editor, it automatically updates. Now we're going to run essentially the same command — yarn redwood generate — but this time we're generating an about page. We don't need to specify a route because it will default to /about. This creates the same three files: an about page component, a Storybook component, and a test component. If we navigate to /about in the browser, it takes us to our about page — which looks much like the homepage, but with "About" in the relevant places. We can do the same thing on the about page.

00:20:07 - Anthony Campolo

We're also going to remove the links and routes

00:20:13 - Anthony Campolo

and say "This page tells you about stuff."

00:20:19 - Anthony Campolo

We got a little code left in

00:20:21 - Anthony Campolo

there.

00:20:23 - Anthony Campolo

Now we want to create a layout for our navigation bar to let us go from one page to the other. We're going to run yarn redwood generate again, but this time we're generating a layout called Blog. Before we do that, I want to show you this: here's where the routes are set up for the pages we just created. We have our route paths — home goes to /, and about goes to /about — mapped to their components, HomePage and AboutPage, each with a name. That's why we call these named route functions — when navigating from one route to another, you use functions that reference these names. Let's look at the layout that was created.

00:21:36 - Host/moderator

Cool.

00:21:38 - Anthony Campolo

I'm just going to grab this whole chunk of code.

00:21:46 - Anthony Campolo

What we're doing here is we're importing Link and routes.

00:21:56 - Anthony Campolo

We have a <Link> set to routes.home() — that's the named route function — and another for routes.about(). The parentheses on the end show it's a function. The children prop is where our pages will be rendered inside the layout. On top we'll have links to the homepage and the about page. If we save this, nothing will happen yet because we have to import this BlogLayout into our homepage. Let's go back to the homepage.

00:22:57 - Anthony Campolo

Let me just type this out.

00:22:58 - Anthony Campolo

import BlogLayout from — and you don't have to use dots or forward slashes to navigate between directories, which you might be used to from React. Instead you just specify the exact directory: src/layouts/BlogLayout. Once imported, you bring it into the JSX: <BlogLayout> with a closing tag, and put your content inside. Now we have this layout. If we go to our about page, though, we won't see that layout because we have to import it there too. We'll do the exact same thing.

00:24:03 - Anthony Campolo

Do that.

00:24:04 - Anthony Campolo

And wrap our page.

00:24:09 - Anthony Campolo

Let's do that again.

00:24:11 - Anthony Campolo

BlogLayout. And now we can navigate between our homepage and our about page. The next thing we're going to do is look at our Prisma schema.

00:24:35 - Anthony Campolo

Close all these up.

00:24:37 - Anthony Campolo

Now we're in our API folder — the backend. We'll go to db/schema.prisma. Let's first delete the comments so we can see what's going on. This is what we saw in the slides: setting our database to SQLite and creating an environment variable for the URL called DATABASE_URL. Then we have the Prisma client generator. This is the example model it gives you, but what we want is the Post model we showed in the slides. Once we've done that, we're going to create a migration. The migration writes all the SQL for you to talk to the database — it creates our tables and shows us the migration that was created.

00:25:51 - Anthony Campolo

Let me close these up.

00:26:08 - Anthony Campolo

It's going to create a migration folder right there and automatically gives you a nice README.

00:26:19 - Anthony Campolo

Let's close all those and open.

00:26:24 - Anthony Campolo

This is the migration, and these are the database steps. Even if you've never read SQL before, it should be at least a little understandable because it looks similar to our Prisma schema and our SDL. We're creating a Post with an id, title, body, and createdAt. Now we have to actually apply that migration to the database, so we run yarn redwood db up — that applies the migration and sets up the database, ready to create blog posts.

The real magic is with this command: yarn redwood generate scaffold post. This scaffolds out our entire blog interface to create, edit, and delete posts. It creates too much code to go into in detail, but if you're interested, I've written a lot about what's going on there, and the documentation at redwoodjs.com is really fantastic. I definitely recommend checking it out.

00:27:52 - Anthony Campolo

We're going to go to /posts, and now we have our interface. It's loading to check for posts in the database — there are none yet, so it says "No posts yet. Do you want to create one?"

00:28:11 - Anthony Campolo

We'll say "Hello Porto,"

00:28:18 - Anthony Campolo

save it, and there's our post. If we click into the post, we see it's at /posts/1 because the ID is 1, and we can see the title, body, and createdAt. We can edit it, and now it's updated. We can also delete a post — it will ask "Are you sure you want to delete post 2?" Hit OK and it's deleted. Let's create a couple more posts. Now we want to render all our posts on the front page. We're going to go back to our homepage and generate a cell. We've generated a page, a layout, and a scaffold — now we're generating a cell with yarn redwood generate cell. I'll call that cell BlogPosts. This will be in our components folder.

00:29:56 - Anthony Campolo

The cell,

00:29:59 - Anthony Campolo

right here, is going to say "Cannot query field 'blogPosts' on type 'Query'. Did you mean 'posts'?" — a GraphQL validation error. What's happening is it knows what you actually want to query: posts, not blogPosts, because that's what our schema defines. This is a nice feature. Let's change this to posts.

00:30:31 - Anthony Campolo

Let me open this up a little.

00:30:33 - Anthony Campolo

We set that to posts, and then in the Success export, also set it to

00:30:39 - Anthony Campolo

posts, set it to posts.

00:30:43 - Anthony Campolo

Save. Now we need to import the cell into our homepage — similar to what we did with layouts, except it's not wrapping anything; it's just a self-closing tag.

00:31:01 - Anthony Campolo

So BlogPostsCell from src/components/BlogPostsCell, and put it

00:31:15 - Anthony Campolo

right here,

00:31:17 - Anthony Campolo

and close it up.

00:31:20 - Anthony Campolo

We're not going to see what our posts say yet — just the ID and its type. That's because our query is only asking for the id. Let's ask for body instead. Now we get the body of the post, but we really want everything: title and createdAt too. That gives us all the information, but it still doesn't look very nice. We'll create a small component here: we map over the posts — taking each post and creating a small component with the id, a title inside an <h2> inside a <header>, the body inside a <p> tag, and the timestamp inside a <div>.

00:32:56 - Anthony Campolo

If we save and look over here, it's going to look a bit more like a blog. There you go — a nice simple blog. But if we actually want this blog to be useful, we want to put it on the internet so people can see it.

We're going to generate our deployment config. This is pretty slick — it's going to create a netlify.toml configuration file and rewrite a couple of things to wire up your API routes on the backend. If you don't know what all of this is doing for you, that's not the biggest deal — you can get up and running before diving too deep. This sets the build command, sets up the database, and creates a dist folder that holds all your static assets after building. You also have your functions and redirects here.

00:34:16 - Anthony Campolo

The other thing it changes — I think it changes this.

00:34:21 - Anthony Campolo

Yes, there we go — it changes the API proxy path to /.netlify/functions. Now that's set up, the only other configuration you need is in schema.prisma: change the provider from sqlite to postgres. Once you've done that, commit everything to Git, because the repository we created is what we'll use to deploy to Netlify.

00:35:11 - Anthony Campolo

All right, that should be everything.

00:35:22 - Anthony Campolo

Now if we go over here,

00:35:25 - Anthony Campolo

this will now be updated with the current state of our project. That was the commit I just made — "Deploy and database setup" — and there's our netlify.toml. Now, this is your Netlify dashboard. I highly recommend all the services I'm going to show you — you can sign up with a free plan. Nothing here requires any money. If you don't have accounts on these sites, I really recommend getting them because they're amazing services. We're going to connect to our GitHub repository here —

00:36:00 - Anthony Campolo

that Jamstack OPO repo — and this is going

00:36:05 - Anthony Campolo

to show the repo we just created, along with the test repo I made beforehand. It automatically sets your main branch to deploy and inserts the build commands and publish directory we saw before. This will start building our site, which takes a couple of minutes — if you're doing this yourself, just hang tight. While that's going, we're going to create our database. The database is where we'll actually store our blog posts, and we do that on Heroku.

There are a lot of different ways to deploy both the frontend and backend. What I'm showing you is just one of many options to get a Redwood app online, but it's the simplest and the one you'll see in the tutorial. We'll name the app redwood-jamstack-opo-db and create it. Once you've done that, go to Resources, search for postgres, select Heroku Postgres, and it'll ask if you want to provision the Heroku database.

00:37:37 - Anthony Campolo

It gives you a bunch of options — pick the free tier and submit. There's your database. To connect this database to our Netlify frontend, go to Settings, then reveal your config variables. This is something you never want to share with anyone and definitely don't want to commit online — after these demonstrations I tear down the project. But this is the DATABASE_URL we'll copy from Heroku and put into our Netlify frontend.

Let's see where the build is at — it's still running and should give us an error at some point because the database isn't correctly connected yet. Let's go ahead and go over

00:38:43 - Anthony Campolo

to our frontend.

00:38:48 - Anthony Campolo

In Site Settings, under

00:38:55 - Anthony Campolo

let's see —

00:38:58 - Anthony Campolo

under Build and Deploy, you have Environment. This is where you edit your environment variables. The first variable is DATABASE_URL in all caps — the general convention for environment variables is all caps — then paste the connection string in.

There's one other important thing I usually forget in these demonstrations: you have to set up connection pooling. You need to make sure it's not trying to connect to your database too many times. Heroku Postgres and many databases allow a lot of simultaneous connections, so you want to tell it exactly how many you want — we'll set it to 1. So I have this saved here: the postgres URL, all the credentials, and then this part: ?connection_limit=1. Take that and put it —

00:40:21 - Anthony Campolo

oops, where'd it go?

00:40:27 - Anthony Campolo

— right on the end of the connection string. That's good to go. There used to be another step you had to do, but you don't anymore.

00:40:38 - Anthony Campolo

Now let's see where this build is at.

00:40:40 - Anthony Campolo

It's actually deployed now. If we look at our site, we'll get an error — because even though we saved our environment variables, we have to rebuild the site so it picks them up. We're going to trigger a redeploy, and then after a minute or two we'll be finished with the presentation. While that's going, are there any questions?

00:41:18 - Host/moderator

You can turn your mic on, or if you have any questions, just write in the chat box. Don't be shy — we are a small group.

00:41:41 - Anthony Campolo

If anyone has any questions, I'm happy to answer. It doesn't matter how basic — I'm happy to clarify anything.

00:41:55 - Host/moderator

No questions.

00:41:56 - Anthony Campolo

Does anyone have questions?

00:42:00 - Host/moderator

I don't, but as someone who's not a developer, it was really interesting to see how easy it is — even for me with basic coding knowledge, it was easy to follow. We have a question from Louise: what would you say is an advantage of RedwoodJS over Gatsby? He's not familiar with Gatsby.

00:42:39 - Anthony Campolo

He's not familiar with Gatsby, or he is?

00:42:42 - Host/moderator

He's not.

00:42:44 - Anthony Campolo

Gatsby is similar in that they're both using React and GraphQL. The main difference is Gatsby doesn't have built-in database support. What we just showed — connecting to the Heroku Postgres database and using Prisma for all the SQL — is the type of thing you don't get from Gatsby out of the box. Gatsby gives you the frontend web layer, which is great for simpler projects like a static blog. Redwood is more for interactive applications where you want users to save data to a database. Does that make sense?

00:43:40 - Anthony Campolo

And the site is now live.

00:43:43 - Host/moderator

Yes. Can you also use services beyond Heroku — like AWS or other third-party cloud providers?

00:44:01 - Anthony Campolo

Yeah, there are a lot of different ways to deploy it. I actually just deployed to Render a couple days ago, and Begin is another one we're starting to look at. You can do it on Vercel and Azure. There are a lot of different ways — some do the frontend and backend in the same service, others let you mix and match. Right now there are no blog posts because we have a brand new Postgres database and it wiped our development data. Anyone who went to this link could create posts and do whatever they want, which is why you delete the database right after. Let's create our first blog post. And if we go back to the front page, it'll show our blog post. There you go.

00:45:05 - Anthony Campolo

That's how you create your whole blog, get it online, and you're good to go.

00:45:10 - Host/moderator

Very nice. Thank you so much, Anthony. I have another question: if you want to combine Redwood with a CMS, is the process similar?

00:45:27 - Anthony Campolo

Yeah, there have been a handful of CMS integrations. Let me pull up the exact ones. There's a very wide range — there are a lot of CMSs out there these days. A couple that community members have played around with are Netlify CMS and Sanity — there are some basic tutorials from the users who put those together. I'd recommend looking at whatever CMS you're personally interested in. If it has GraphQL, it should be pretty easy to wire up, and even if it doesn't, there are other ways to do it.

00:46:15 - Host/moderator

Cool, very nice. Netlify CMS usually works great as an open-source CMS. Does anyone have additional questions for Anthony? If not, thank you again so much.

00:46:52 - Anthony Campolo

Let me share all of these links so people can see them.

00:46:57 - Host/moderator

Yes, that's great. It was super helpful and really easy to follow. Thank you so much.

00:47:09 - Anthony Campolo

Awesome.

00:47:11 - Host/moderator

I hope to see you around again sometime soon.

00:47:14 - Anthony Campolo

Totally, anytime.

00:47:16 - Host/moderator

If people have any questions after the event, how can they reach you?

00:47:25 - Anthony Campolo

My Twitter is always open — that's a good way to get in touch. I just posted it in the chat: it's @ajcwebdev. That's where I am on GitHub, Dev.to, and most places. I'm happy to talk to anyone. We have a community forum and a Discord, so if you want to get involved in any capacity, there are a lot of different ways to do it. Just check out the redwoodjs.com homepage for all of that.

00:47:57 - Host/moderator

Amazing. Thank you so much. Thank you again for joining us — me and Anthony — on this journey of learning how to use RedwoodJS. I'm eager to try it myself. I'll see you all around. Don't forget we have a discount code for the GemDev conference happening January 28–29. The code is GEMSPEC OPO. Thank you everyone, and thank you again Anthony — it was lovely.

00:48:42 - Anthony Campolo

Thank you for having me.

00:48:44 - Host/moderator

Bye.