RedwoodJS the Universal Deployment Machine - Mintbean

Episode Description

Anthony Campolo introduces RedwoodJS, walks through its architecture, and live-demos building and deploying a simple app to both Netlify and Vercel.

Episode Summary

Anthony Campolo presents RedwoodJS to a Mint Bean community audience, framing it as a full-stack serverless framework for the Jamstack that doubles as a surprisingly effective learning tool for developers. He begins by explaining the framework's philosophy and its creators—Tom Preston-Werner and Peter Pistorius—before walking through the architectural diagram, breaking it into its web front end and API back end. The web side resembles familiar React setups but includes built-in routing, layouts, and cells for data fetching, while the API side uses Prisma for database access and GraphQL as its core data layer. Anthony then shifts into a live demo, generating a new Redwood project, creating home and about pages with linked navigation, pushing the code to GitHub, and deploying the same app to both Netlify and Vercel within the span of the talk. Along the way he fields audience questions about page generators, hot reloading, and deployment use cases. He also showcases a more advanced personal project built with FaunaDB and GraphQL, illustrating how Redwood connects to distributed databases. The session closes with a discussion of why supporting multiple deploy targets matters—developer choice, portability, and the ability to avoid provider lock-in—reinforcing Tom Preston-Werner's vision of a "universal deployment machine" where code goes from text to production with minimal friction.

Chapters

00:00:00 - Introduction and the Teaching Power of Full-Stack Jamstack

Anthony opens by thanking the Mint Bean organizers and situating himself within the RedwoodJS community—not as a core contributor but as an enthusiastic advocate who finds the framework uniquely approachable. He references Monarch's idea that full-stack Jamstack frameworks can serve as powerful teaching tools and shares his own experience of learning React through Redwood.

He acknowledges that combining so many cutting-edge technologies under one roof sounds intimidating, but argues the way Redwood assembles them makes the whole greater—and more comprehensible—than the sum of its parts. He previews the session plan: a short slide deck followed by a live demo where the audience will watch him build a project and deploy it to two different providers, all within roughly 30 minutes.

00:02:27 - What RedwoodJS Is and Who Built It

Anthony defines RedwoodJS first in industry jargon—"a full-stack serverless framework for the Jamstack"—then translates that into plain language: a tool for generating web applications quickly and confidently. He introduces the core team: co-creators Tom Preston-Werner and Peter Pistorius, community builder Rob Cameron and his Repeater.dev project, and community manager David Price.

He shares key quotes from Tom's podcast appearances on JS Party and Shop Talk, highlighting the vision that full-stack web development is the next evolution of Jamstack and that the ultimate goal is a "universal deployment machine"—write code, commit to GitHub, and have it deployed automatically. Anthony recommends listeners explore Tom's interviews to understand the deeper philosophy driving the project.

00:06:04 - Redwood Architecture: Front End and Back End Breakdown

The discussion turns to Redwood's architectural diagram. Anthony focuses on the two main folders developers work in: the web folder (front end) and the API folder (back end). He compares the web side to Create React App, walking through index.html, the app component, built-in routing, pages, and how Redwood's Link and Routes system eliminates the pain of configuring React Router manually.

He briefly introduces layouts for wrapping shared UI elements like navbars around pages, and cells for declarative data fetching that handle loading, empty, error, and success states out of the box. On the API side, he covers Prisma as a query builder that lets developers stay in JavaScript rather than writing raw SQL, the schema definition language for GraphQL, services, and serverless functions that tie everything together.

00:11:52 - Live Demo: Generating Pages and Setting Up the Project

Anthony switches to his terminal to show the project he scaffolded with yarn create redwood-app. He walks through the default starter page, the readme's warning about pre-1.0 stability, and a tangent about semantic versioning—which Tom Preston-Werner also created. He notes that the team is aiming for a 1.0 release by year's end and highlights the tutorial as a standout learning resource.

He then runs the page generators, creating a home page and an about page, and manually adds navigation links between them. Along the way, audience members ask about how the generator names pages and routes, and whether the dev server auto-reloads on save. Anthony confirms both, emphasizing that Redwood prioritizes developer experience so that common workflows feel frictionless.

00:18:00 - Pushing to GitHub and Deploying to Netlify

With the two-page app ready, Anthony initializes Git, commits the project, and pushes it to a new GitHub repository. He then demonstrates deploying to Netlify using Redwood's built-in deploy generator (yarn rw generate deploy netlify), which creates a netlify.toml configuration file with the correct build commands. He explains that TOML—another Tom Preston-Werner creation—provides the build instructions Netlify needs.

A small hiccup arises when the config file doesn't sync to the repo, so Anthony edits it directly through GitHub's web interface. He kicks off the Netlify build and, while waiting, fields a lighthearted question from Rob Cameron about Redwood stickers being available worldwide for free—a moment that underscores the community's friendly culture.

00:26:19 - Deploying to Vercel and the Universal Deployment Machine

Anthony shifts to the Vercel deployment, showing that the only required change is updating the API proxy path in Redwood's own TOML config. He edits the file on GitHub, imports the repo into Vercel, and notes that Vercel's framework preset auto-fills the build settings. Both deploys run in parallel on their respective cloud servers, unaffected by his streaming bandwidth.

While the builds finish, he connects the exercise back to Tom's universal deployment machine concept: the same codebase, committed once to GitHub, can be picked up and deployed to multiple providers with minimal configuration changes. This portability is central to Redwood's design philosophy and demonstrates that the framework avoids locking developers into a single hosting vendor.

00:28:33 - Showcasing a FaunaDB Project and GraphQL Architecture

Responding to Claire's question about real projects, Anthony walks through his Redwood-Fauna integration. He explains FaunaDB as a globally distributed database designed to minimize latency by placing data close to users, contrasting it with traditional monolithic architectures where everything lives on one machine. The project uses GraphQL as a bridge between Redwood's front end and Fauna's back end.

He briefly tours the accompanying blog post, covering the schema definition language, environment variables for the Fauna API key, Fauna's own query language FQL, and how cells display fetched data. He mentions his full talk at GraphQL Texas for anyone wanting deeper detail, and notes the project was novel at the time—no one had wired Redwood to Fauna before.

00:33:46 - Deployment Results, Q&A, and Closing Thoughts

Anthony confirms both deployments are live, clicking through the Netlify and Vercel URLs to show identical copies of the app. He recaps the achievement: within one talk, the audience watched a project get created, routed across multiple pages, and deployed to two providers. The audience asks about practical use cases for multi-target deployment.

Anthony frames it as developer choice and portability rather than running both simultaneously—some developers prefer Netlify's auth tools, others prefer Vercel's ecosystem, and having options prevents lock-in anxiety. He also suggests it's useful for A/B testing performance issues between providers. The session wraps with mutual appreciation between Anthony and the Mint Bean community, and a nod to a fellow audience member's Bison article.

Transcript

00:00:04 - Anthony Campolo

Hey everyone. Thanks for being here. Thank you to Mint Bean for having us. Thank you to Jennifer and Maggie for helping set this up and run this. Really excited to be here to talk with you guys about RedwoodJS. Mint Bean has done quite a few events already with the Redwood community, doing some talks with some of the different core community members and creators of the framework. I'm pretty low down on the totem pole. I'm just a guy who really enjoys the framework, finds it really interesting, and I like going out and teaching it to people and explaining how it works and what the ideas behind it are, because I think it's a really fascinating project. And I know Monarch a little bit, and he's talked about how he thinks this new space of what we're calling full-stack Jamstack frameworks have a lot of potential as teaching tools. And when he first told me this, I got the feeling that he has pitched this idea to a lot of people and they find it a bit unintuitive. Whereas I was immediately like, yeah, duh. That's exactly what happened to me.

00:01:15 - Anthony Campolo

I found these frameworks and I was learning React at the same time. And when I found Redwood, it just made sense to my brain in a way that the other stuff I was learning didn't. So the idea of using this as a teaching tool can sound a little crazy at first because it's so many different technologies that are cutting edge and can be really complicated to wrap your head around, but the way that they've all been put together makes them a lot more comprehensible than you would think at first. So I'm going to go ahead and get my slides up. We'll do a few slides and then we will do an actual live demo where I'll build up a really simple project and show you guys how to deploy it to two different deploy targets. RedwoodJS and the Universal Deployment Machine. These are just some resources of what we'll be going over. If you go to these links right now, they will not go anywhere because we're going to create them. But if you just add a dash test next to those after the rw, you can kind of see the trial run I did yesterday as I was building this out.

00:02:27 - Anthony Campolo

We're going to basically make a GitHub repo and then we're going to deploy our project to Vercel and to Netlify, and we can do all of that in the span of just 30 minutes, which is pretty amazing. All right, RedwoodJS. It is a full-stack serverless framework for the Jamstack. This is one of those definitions that if you already know what these words mean, then you'd be like, oh yeah, sure, serverless framework for the Jamstack, duh. But if you've never heard of serverless or Jamstack, this may be a bit incomprehensible to you. So a slightly simpler, more basic definition that I kind of like is that it's a program for generating web apps, which basically means it's a tool that we use to build things that we put on the Internet. So Redwood is about enabling developers to create websites or web applications quickly and with confidence that what you're creating is going to work the way you expect it to. These are the core members who are working on it. Tom Preston-Werner is the co-creator with Peter Pistorius. They were working on this for over a year, talking about it probably even longer than that, before it launched in March.

00:03:47 - Anthony Campolo

And so they're really the core in terms of the ideas that formed the framework. And then Rob has come on to help with creating the tutorial and for building out some projects around Redwood. He's working on something called repeater.dev, which is a background job processing tool. And then David Price is the community manager type guy. So if you get into Redwood, if you're going on the forums, if you're talking in the Discord, you'll definitely see him a lot. He'll be answering questions for you, he'll be helping you out. Super kind guy. And he's really helped me get spun up in the community and get going. So this is a totally real quote that was definitely not taken out of context. "Redwood is the best framework ever created, if not the culmination of nearly 80 years of computer programming methodologies." RedwoodJS core member Rob Cameron. Now these are quotes that are less taken out of context. This is Tom from two different podcast interviews that he's done. The first one was from JS Party and the second one was from Shop Talk. So I'm just going to read these out for you.

00:04:58 - Anthony Campolo

"Full-stack web application development is the next evolution of Jamstack that becomes a primary place that you would deploy a full-stack web application. And that's what RedwoodJS is about." And then the second quote is where he talks about the Universal Deployment Machine, which is what this talk is about. "My dream of a future is for something I call a universal deployment machine, which means I write my code, it's all text, I just write text. Then I commit to GitHub. That's picked up and it's deployed into reality. That's it. That's the whole thing. That's what I want. That's what I've been looking for." So if you're trying to figure out what Redwood is about, I really recommend you check out some of Tom's podcast interviews because he's gotten really in depth talking about what Redwood is and what it's supposed to do. And I was listening to these podcast interviews as they were coming out and it's what helped me wrap my mind around what Redwood is and what it's supposed to do. Now this is the architectural diagram of how Redwood works. And this could be a little overwhelming the first time you look at it.

00:06:04 - Anthony Campolo

So we're going to break this down into just a few pieces. The points that you really need to focus on as a developer are the stuff on the left where it says "Redwood codebase." And then we have the API folder, which is our back end, and then we have our web folder, which is our front end. So let's look at each of those individually. The web front end. If you've ever used Create React App, or if you've built a Vue project, if you've used any sort of front-end JavaScript-heavy frameworks, they will look fairly similar to this. You have an index.html and you have an index.js, and what's happening is you have a div in your index.html which will say "app." And then you will load the app into that div. And then all the things that your app is will be contained inside that one app component. And then they also have a routes folder for your routing. So a lot of the routing is handled for you here. I'm going to show you all the pieces of a regular Redwood project, but actually most of these we're not going to be using because we're going to be focusing on just the deployment.

00:07:20 - Anthony Campolo

So pages is really the only thing we're going to be using. We're going to make a page and we're going to link between two different pages. So on the right here we have a pretty standard component—it's a homepage component. So we're declaring our homepage on line three and then we're setting that equal to an arrow function. And then in the arrow function we're returning that component right there. So we have our little fragments, the opening and closing brackets that are holding all of our HTML. And then we have an H1, a simple header that says "Mint Bean," and then a paragraph that says "this is the home page." And then we have a nav bar with an unordered list of two list items. And you can see there we have link to route home or link to routes about. RedwoodJS has its own built-in router. So if you've ever used React Router and had to figure out how to set up your routes and your links and all that, you don't have to do that with Redwood. It's all baked in from the beginning, which is really nice, as routing is not something a beginning developer really wants to think about.

00:08:35 - Anthony Campolo

It's going to cause you far more problems than you'll ever be able to solve. We won't look at layouts today, but this is how you could basically take your navbar and have it be around all of your pages by default. So you don't have to keep creating your navbar and putting it in every single page. You can just create a generic layout that all of your pages will live inside. Then we won't look at cells at all either, but this is how we do data fetching. So if you set up your database and you have blog posts in your database and you want to get those blog posts back out, this is how you would do it. And it's set up in a way where you don't have to figure out whether your data is loading or empty or if you've got an error or if it's worked or not. It's all baked in out of the box. So a lot of this stuff I've talked about in other talks. If you want to go deeper into the actual Redwood architecture—since we'll be talking about deployment specifically—I just wanted to give you a brief idea of these things.

00:09:37 - Anthony Campolo

But you're not going to have to worry about any of that. The next thing we're going to look at is the API section. So this is the top left, and again the vast majority of the stuff we're not going to use. So your back end is how you get your database set up and how you get your front end to talk to your database, and we use something called Prisma, which is a query builder. If you have ever heard of an ORM—object-relational mapper—it's a little bit like that. It's just a way to simplify talking to our back end so we don't have to write raw SQL. If you've ever had to write raw SQL, it's very different from writing JavaScript. So this helps us stay in JavaScript land and not have to jump over into SQL land as much. So we have a Prisma schema where we set our data source and create our models. We won't be doing any of this today. And then you'll create a schema definition language. This is all related to GraphQL stuff, if you're interested in GraphQL. Redwood is a really, really cool project to be on because it's all based around GraphQL.

00:10:44 - Anthony Campolo

That's kind of the most baked-in, fundamental part of it. I can imagine Redwood without React. I couldn't really imagine Redwood without GraphQL. And then your services is how your back end talks to your database, and then this is your database client, so you don't really need to worry about any of that. And then we've got our functions here, which is what stitches together all of our back end. So that's kind of a teaser for people who want to learn more about the whole stack. But what we're going to do is spin up a simple little project. I've already gone ahead and created it beforehand, because it might take a little while and streaming will slow things down. So what we did so far is I entered this command: "yarn create redwood-app ./mintbeanrw." So that created a

00:11:52 - Anthony Campolo

folder, which is Mint Bean. I got a bunch of stuff here.

00:11:58 - Anthony Campolo

Mint Bean Redwood. And then we did "yarn redwood dev," which is what started our development server, and it opened up this thing right here. So this is your main Redwood kind

00:12:13 - Anthony Campolo

of starter page, and I'm going to open this up.

00:12:28 - Anthony Campolo

So this is going to be our project just out of the box. I've generated this project and I haven't done anything else with it. So the first thing we should do, because we are responsible developers, is take a look at our readme. So if we take a look at the readme, this is going to give us just a little bit of information in terms of where Redwood is at right now. You'll notice that it says, "Warning, RedwoodJS software has not reached a stable version 1.0 and should not be considered suitable for production use." Now this just means that Redwood is currently in the process of being created in the sense that it is not at version 1.0. If you've ever wondered how do we even decide what makes something 1.0 versus 0.9 versus 0.0.73, that's actually interesting because what we think of as versioning numbers came from the creator of Redwood. Tom Preston-Werner created something that we call semantic versioning. So "semantic" is a fancy word that means "meaningful." Semantic versioning just means that our versions should have meaning. So if we are before version one, that should mean that it's not ready yet.

00:13:50 - Anthony Campolo

And that's kind of the whole point of not being at version one. So we're working on it and the plan is to get to version one by the end of this year. So right now is actually a really, really exciting time to be involved in RedwoodJS, because we're kind of right at that point—we've been doing this, but the whole team has been doing this for years. I've been in this for five months or so. And we're about to get to the point where we're really going to be pushing this to be: this is it, this is ready to go, this is the thing, we're almost there. We also have the tutorial, the docs, and the community link. These are all really fantastic resources. The tutorial especially was kind of life-changing for me because it's what really helped me understand the whole system in a way that just clicked immediately, which was really cool. So I highly recommend checking out the tutorial. They put a ton of work into it and we're actually working on kind of the second iteration of it right now, which is really exciting.

00:14:55 - Anthony Campolo

And then it gives you your setup commands. We use Yarn instead of npm, and then you just do "yarn redwood dev" to fire up your dev server. You can shorten "redwood" to just "rw." So now that we've got our things set up, let's get this

00:15:13 - Anthony Campolo

over here and we'll get this over here.

00:15:20 - Anthony Campolo

The first thing we're going to do is generate a page. So we're going to do "yarn redwood generate page home" and then it's going to create a home page that's going to go to our home route. So that's what that slash is. And then what this is going to do is create a page under web/src/pages/homepage/homepage,

00:15:46 - Anthony Campolo

and there it is.

00:15:48 - Anthony Campolo

It may look like a lot going on in terms of your project structure, but once you get used to it, you'll kind of know where everything is, and it's really nice to use. So here we've got our homepage, and this is our homepage. So if we want to edit this,

00:16:07 - Anthony Campolo

see what it looks like, you can do that, and we can do that. And there we go.

00:16:24 - Anthony Campolo

And if we want to create another page, go back here.

00:16:30 - Anthony Campolo

Sorry, all my Zoom stuff always gets in the way.

00:16:34 - Anthony Campolo

"Redwood generate page about." So this is going to do the exact same thing, except it's going to generate an about page instead of a homepage, and it's going to put it in the same place—our pages folder. And every time it generates a page for you, you'll notice that you have a couple other things there. You also have a test file and a Stories file, and those are just for using Jest and Storybook, which are going to be a bigger focus for the new tutorial. So if you don't know much about testing or Storybook, that'll be a really good opportunity to learn about that. So here, now we have our homepage. If we just went to about, we've got our about page, and we want to get the links on both so we can switch from one to the other. So normally this is where I would go create a layout with a navbar and all that kind of stuff, but just to save some time, I'm going to skip past that and we're just going to throw these links into each of them so that we can switch between the two pages easily.

00:17:52 - Anthony Campolo

So, yeah, this here and this here. So now we should have both of our links in each of them, so

00:18:00 - Anthony Campolo

we can now switch between our homepage and our about page really easily. Okay, so that's our whole project right now. And now we're going to deploy this and get it onto GitHub. There's a couple different ways to do it. The way I'm going to do it is just create a Git repo: git init, git add, git commit "first commit." And then what we're going to do is create the repository over here, and then we're going to use this huge, absurd git command to shove this whole project up into that repo. So we're going to create a new repository and we're just going to call it—I always add an extra E. Mint Bean Redwood.

00:19:03 - Anthony Campolo

And then that's all we need to do.

00:19:07 - Mintbean moderator

Anthony, we have a question.

00:19:09 - Anthony Campolo

Sweet, hit me with it.

00:19:10 - Mintbean moderator

So it says from Adrian: "home and about don't matter as far as the name. It'll just make a folder called 'name page' and then the default routes are slash, whatever you named it."

00:19:21 - Anthony Campolo

Yeah, you got it. So the generator is set up in a way that makes it really easy to create the page and have it say whatever you want. And then in this routes folder over here is where it's creating. So we did home, so it just does home and then adds "page" to the end of it. And then it gives you the route just like you were saying. So then the about page—we did about, so it added "page" to it and then created the /about route right there. So the generators are really sophisticated in that they're set up in a way where you can really just flow really easily and say, I want this kind of page, I want to go to this kind of route. And then bam, it does it. So yeah, did that answer the question?

00:20:01 - Mintbean moderator

And then one more question.

00:20:02 - Anthony Campolo

Yeah.

00:20:03 - Anthony Campolo

Oh yeah.

00:20:07 - Mintbean moderator

And the second question is: when you run the dev command, it's automatically watching, right?

00:20:12 - Anthony Campolo

Yes, exactly. So that's why when I was editing and saving, it was automatically being updated over on the side. Your dev server is already configured to watch for changes and all that setup. The big part of Redwood is DX—developer experience. Have you ever heard that term? It's kind of a term that's getting to be more popular these days. They've thought a lot about the developer experience, so the tool is very much made to just be easy to use and to make sense, to help you move quickly. Cool. All right, so I was about to do the git command. This is going to basically take our project and just push it into that repo that we just made, the mintbeanrw. And then if we go back over here and refresh, we should see our project appear.

00:21:17 - Anthony Campolo

See, this is still going.

00:21:20 - Anthony Campolo

It's funny, everything goes so much slower when you're streaming. So once that is done, we're going to be going to Netlify and Vercel to deploy. Do people at Mint Bean have much familiarity with those kinds of services? What kind of stuff do you guys usually use when you're deploying?

00:21:48 - Mintbean moderator

I think Claire can speak on that. Claire?

00:21:52 - Claire / audience questioner

In hackathons, yeah, I use Netlify a lot. I find it very simple.

00:22:00 - Anthony Campolo

Yeah, Netlify is great. Yeah, I think for our hackathons mainly.

00:22:05 - Mintbean moderator

A lot of our devs use Netlify or GitHub Pages and sometimes Heroku. But yeah.

00:22:15 - Anthony Campolo

I'm not sure why this is still hanging. I should have been done by now. Let's just try that again, see what happens.

00:22:39 - Anthony Campolo

All right, good deal. So now we see.

00:22:41 - Mintbean moderator

Anthony, we have another question.

00:22:43 - Anthony Campolo

Cool. Yeah.

00:22:44 - Mintbean moderator

So it's from Rob. Anthony, is it true that anyone can get RedwoodJS stickers mailed to them anywhere in the world for free by visiting this link?

00:22:58 - Anthony Campolo

That is true. I have stickers. They're right over there. I'm not sure exactly where they are, so I'm not going to run and grab them. But yes, we do send stickers to anywhere in the world. It's very, very important that you get your stickers. Stickers are the most important part of Redwood. There will be no Redwood without stickers. All right, sweet. So now we have our GitHub repo set up. We can now deploy our stuff.

00:23:26 - Anthony Campolo

So let me go back and grab my couple extra commands here that we were working with.

00:23:33 - Anthony Campolo

So as we were showing with the generator for generating pages and things like that, we have the same thing for deploying. So we have this super handy generator here for deploying to Netlify: "yarn redwood generate deploy netlify." So what this is going to do is create a netlify.toml. And as I already talked about how semantic versioning was created by Tom, so was TOML. TOML is named after Tom. It is a configuration language—Tom's Obvious, Minimal Language—and it gives you the build commands. So when you upload your project to Netlify, it is going to take your whole project and run these commands, and that's what's going to create the thing that's actually going to be put up onto the Internet. So that is what this command here does.

00:24:32 - Anthony Campolo

So we're going to go over here and

00:24:34 - Anthony Campolo

we're going to create a new site, new site from Git. And then we're going to select GitHub—because who uses BitBucket? I certainly don't know anyone. And then we have Mint Bean Redwood, and then this will search through all of our repos to get our Mint Bean. And then it's going to.

00:24:58 - Anthony Campolo

Oh, it did not put our build command in automatically. Usually it does.

00:25:04 - Anthony Campolo

Oh, I know why—because I changed this but I did not actually push it up to my GitHub repo.

00:25:17 - Anthony Campolo

I'm going to just real quickly throw this up with GitHub's graphical editor

00:25:27 - Anthony Campolo

because my GitHub command-line authorization has been messed up and I never bothered to fix it. So I just do this.

00:25:47 - Anthony Campolo

Okay, I'm going to do this instead. I'm going to just do this down and dirty and create a new file and this will be netlify.toml. And that'll be there and we're just going to do that. Okay, so this should now be good to go.

00:26:19 - Anthony Campolo

All right, look at that. Now we've got our build commands in there and we're going to just deploy it. This is going to take a couple minutes. While that's going, I'll show you what we do for Vercel. Vercel is going to make just a small change to, I believe, our Redwood toml. So after we do that, you can see the changes it made. What all this did is it just changed your API proxy path from Netlify functions to /api here.

00:26:59 - Anthony Campolo

So I'm going to just make sure I change this here. So this will be netlify—wait, no, we want redwood.toml and we'll be editing the API proxy and then commit changes.

00:27:21 - Anthony Campolo

And then now this will have our

00:27:24 - Anthony Campolo

build set up for Vercel, and we're going to do the same basic thing. And this will be github.com/ajcwebdev/mintbean-redwood.

00:27:46 - Anthony Campolo

And then here you can see that we have this framework preset and then this is using the same build command we're using before. So this is already all set up and good to go. And then this is going to deploy, and this is probably still going. Yep, that's still going. And then this is going to take just a little bit. Luckily, since this is all happening on their servers, me streaming will not affect it. But are there any other questions while we're waiting for this to go through? There's some other things I could talk about as well, if anyone's curious about the history of Redwood and where it came from.

00:28:33 - Claire / audience questioner

Hey Anthony, it's Claire.

00:28:35 - Anthony Campolo

Yeah, what's up?

00:28:36 - Claire / audience questioner

I was wondering if you have any project that you've built with Redwood that you wouldn't mind sharing with us.

00:28:44 - Anthony Campolo

Yeah, so I have built out a couple things. The one that is probably the most interesting to me is the Redwood Fauna project. So this isn't going to look super exciting, but trust me, it is. This is a project that I created with FaunaDB. You guys are probably not very familiar with something like FaunaDB. So FaunaDB is a database that is made to be distributed across the globe. If you think about how databases and websites used to work in the past, we used to have what were called monolithic apps. A monolithic app would mean that you would have your database and your front-end React project—it wouldn't have been React at the time, but you'd have your front end, your back end—it would all be in one big project, and that would all live on an actual physical machine somewhere. There'd be a computer probably in some guy's basement somewhere that people would be accessing. So I would go on my computer and type in a URL and my computer would reach out through the series of tubes that is the Internet and go to that computer.

00:30:01 - Anthony Campolo

Now what we want is we want everything to be everywhere. We want someone, if they actually want to find a website, to take as short a trip through that series of tubes as possible. So we want it to get to a server that could preferably be right down the street from you instead of an entire country or ocean away. So that's the main idea behind Fauna: getting your database distributed around the world so that everyone has kind of short hops to get there. And the reason I thought it was super interesting is just because you use GraphQL as a layer in between to get Redwood to talk to Fauna. So there is an article about this where I explain what I did. It talks about what Redwood is, then it talks about what Fauna is, and then it walks you through creating the Redwood application. So what you're seeing here should look pretty familiar. This is basically exactly what we did. And then you generate a homepage just like we did, and then create your homepage, and then you bring in a cell.

00:31:14 - Anthony Campolo

So this is the stuff that we didn't talk about too much. And the cell is what's doing your data fetching into the database. I was talking about how it will tell you whether you have posts or not kind of out of the box, saying, hey, we don't have any posts yet. And then we create our schema definition language, which is how your front end and your back end talk to each other. So it knows what a post is. A post is something that has a title, and that title is a string. And then you set up your GraphQL request, and this is where you're using an API key for Fauna. So if you've ever heard of the 12-Factor App and this idea of how we configure our project and how to use environment variables, this is very much in that vein. And then we set up a service to just hit the back end. And then I walk through how you actually use Fauna. Fauna has its own query language, and what that means—we were talking a little bit about SQL and how that works.

00:32:20 - Anthony Campolo

So instead of SQL you use something called FQL, or you can just use GraphQL commands. And so if you've ever used Mongo and you know what a collection and a document database is, this will be kind of familiar. So I show how to just create a couple simple blog posts, which is not really a blog post, it's just a title. And then I walk through how to work with the query language, and then you end up with the front end, your cells talking to your back end. I actually did a whole talk about this, so I'm kind of glossing over tons and tons of information here. It took me a whole 20-minute talk to explain this whole project. But if you're interested, it was at GraphQL Texas and the talk was "Architecting a Full-Stack Jamstack Application with FaunaDB, RedwoodJS, and GraphQL"—

00:33:16 - Anthony Campolo

I'm pretty sure that was the title.

00:33:18 - Anthony Campolo

So yeah, that's the Redwood project I'm probably most proud of right now, and it definitely took a lot of work and was something cool and new that no one had really done before. So it was really exciting to get to do. Sweet, so I hope that answered your question. Check it out—this is our website. We can go to our different pages, just like we see. And then we also can go to

00:33:46 - Anthony Campolo

Vercel, and if we go to Vercel,

00:33:49 - Anthony Campolo

we can visit our website, and bam—exact same thing. So these are now on the Internet, and if any of you now type in this link, you will see the thing I just made. So in the span of this whole talk, we created a project, created multiple pages, routed between them, and deployed to two different providers. So yes, that is the talk. Thank you all.

00:34:19 - Audience questioner

Super cool.

00:34:20 - Anthony Campolo

Thank you for listening. Yeah.

00:34:21 - Mintbean moderator

Thank you everyone. That was a really great talk. I feel like I'm ready to go create a RedwoodJS app, and there's a great community behind it. Are there any questions for Anthony? Last-minute questions, even for Tom or any of the other community members?

00:34:41 - Audience questioner

I got a question. What kind of use cases do you see for the multiple deployments? I could think of a couple, but I'm curious what it was initially intended for and how you guys see that being applied.

00:34:57 - Anthony Campolo

Yeah, I would see it as choice for the developer themselves. Some people are going to want to use Netlify, some people are going to want to use Vercel. Some people already know Netlify's identity auth provider really well, whereas some people may know Vercel's service really well. So it's not so much that we think there's a good use case for deploying to both of them. For me, it's more about giving that option to developers and showing that we're not favoring one over the other—that Redwood itself is portable, that it can be easily deployed to different targets because it's good to have that flexibility. And people are so worried about lock-in. People talk about lock-in all the time. I'm not particularly worried about getting locked in to Netlify because they seem to keep getting better. So if the thing I'm locked into continues to improve, I don't really see that as a problem. But we know that this is a huge concern for a lot of people, so we want to give lots of different deploy options.

00:36:01 - Anthony Campolo

You can also deploy to the Serverless Framework—that's another deploy target that community members have done. I did not demonstrate that because doing so would have required explaining how to set up AWS credentials, which would have been way outside the scope of this. But yeah. And then also it'd be good for testing. If you want to throw it up on two different targets and you're having some sort of performance issue, is the performance issue your app or is it the provider? This would be a good way to kind of A/B test between the two of them. Also, you're the guy who wrote the Bison article, right?

00:36:40 - Audience questioner

Yeah, that's me.

00:36:42 - Anthony Campolo

Cool. Yeah, it was great. I loved it. It was funny—I was going to write it myself if someone else didn't. Yeah, it's really fantastic.

00:36:51 - Audience questioner

Thanks. I appreciate that a lot. Great talk, by the way. I didn't get to say that, but this has been a great introduction. I appreciate it.

00:36:58 - Anthony Campolo

Cool.

00:36:59 - Mintbean moderator

Great.

00:36:59 - Anthony Campolo

That's what I was hoping for.