What is RedwoodJS

Episode Description

Drew McLellan talks with community champion Anthony Campolo about RedwoodJS, a full-stack serverless Jamstack framework built on React, GraphQL, and Prisma.

Episode Summary

This episode explores RedwoodJS, a full-stack serverless framework for the Jamstack, through a conversation between Drew McLellan and community contributor Anthony Campolo. The discussion traces Redwood's origins back to creator Tom Preston-Werner, the founder of Jekyll and former CEO of GitHub, whose long-standing vision of a "universal deployment machine" shaped the framework's philosophy. Anthony explains how Redwood is structured as a monorepo with a React-based front end and a GraphQL-powered back end deployed as serverless functions, with Prisma handling database interactions. Key framework features are unpacked, including cells for declarative data fetching, sophisticated CLI generators reminiscent of Ruby on Rails scaffolding, and built-in authentication options through services like Netlify Identity and Auth0. The conversation addresses practical concerns around maturity, vendor lock-in, and long-term maintainability, with Anthony noting that several apps are already running in production and that the architecture is intentionally modular despite being fully integrated. The episode closes with a look at the roadmap toward version 1.0 and guidance on how newcomers can get started through Redwood's tutorial-driven development approach.

Chapters

00:00:00 - Introduction and Weekly Update

The episode opens with a brief introduction to the topic of RedwoodJS before transitioning into the weekly roundup of recent Smashing Magazine articles. Drew highlights pieces on running Google Lighthouse programmatically for quality monitoring, animating React components with GreenSock, and designing for user attention.

The roundup continues with coverage of advanced GraphQL usage in Gatsby websites and a comparison of CSS-in-JS styling methods in Next.js. These articles set a thematic backdrop for the main conversation, touching on React ecosystem tooling and GraphQL — both central to the RedwoodJS framework that the episode will explore in depth.

00:03:17 - What Is RedwoodJS and Where Did It Come From

Drew introduces Anthony Campolo, a Lambda School student and Redwood community champion who authored a 12-part series on the framework. Anthony defines RedwoodJS as a full-stack serverless framework for the Jamstack, explaining that it pushes the boundaries of what Jamstack applications can be by extending deployment simplicity from the front end to the back end.

The conversation traces Redwood's lineage to creator Tom Preston-Werner, known for Jekyll, TOML, and co-founding GitHub. Anthony explains how Redwood's convention-over-configuration philosophy draws heavily from Ruby on Rails, but applies those principles using modern tools like React, GraphQL, and serverless infrastructure. The framework's monorepo structure — with separate web and API folders — is introduced as a foundational concept.

00:07:00 - React, Cells, and the Front-End Architecture

Anthony explains Redwood's front-end setup, which centers on React paired with a custom router and GraphQL integration through Apollo Client. The framework aims to eliminate the startup cost of wiring together best-of-breed tools, with Tom Preston-Werner's tagline being that Redwood handles your Webpack configuration so you don't have to.

The discussion focuses on Redwood's concept of a "cell," a declarative pattern for data fetching that manages loading, error, success, and empty states automatically. Anthony explains that while this pattern existed informally across the React community, Redwood formalized it to remove boilerplate and conditional logic. The cell abstraction hides Apollo's complexity, letting developers simply write GraphQL queries — fulfilling the original promise of GraphQL as a simple query language for front-end developers.

00:14:01 - GraphQL, Prisma, and the Back End

Drew and Anthony explore how GraphQL serves as the communication layer between Redwood's front end and back end, replacing traditional REST APIs with flexible, hierarchical queries. Anthony recommends that newcomers have basic familiarity with both Create React App and GraphQL before starting with Redwood, as GraphQL is central to the framework's architecture.

The back-end discussion shifts to Prisma, which handles database interactions through a schema-driven approach. Anthony explains how Prisma lets developers define models in a schema file and then manages migrations, table creation, and SQL generation automatically. The default tutorial setup uses SQLite for development and Postgres on Heroku for production, reflecting Redwood's preference for relational databases — a philosophy inherited from Tom's experience with Rails and Active Record.

00:20:26 - Deployment, Serverless Architecture, and Flexibility

The conversation examines how Redwood packages the back end into a single GraphQL handler deployed as an AWS Lambda function through Netlify. Anthony explains that the serverless deployment is handled automatically — developers don't need to manage Lambda functions directly. The full deployment workflow involves Netlify for the front end and Heroku Postgres for the database, connected through simple configuration variables.

Drew raises the question of vendor lock-in given Tom Preston-Werner's connection to Netlify's board, but Anthony emphasizes that the team actively pursues deployment flexibility. Work is underway for Serverless Framework, Azure, and Google Cloud support, and a Vercel deployment option was recently added. Tom's vision of a "universal deployment machine" underpins this philosophy — the goal is for deployment to be so seamless that developers simply stop thinking about it.

00:26:09 - Generators, Authentication, and Developer Experience

Anthony highlights Redwood's CLI generators as one of its standout features, drawing a direct parallel to the famous DHH Rails demo where a blog is built in 15 minutes. Redwood's generators can scaffold pages, layouts, cells, full CRUD interfaces, authentication, and even Tailwind CSS configuration. Drew notes how valuable scaffold-generated admin interfaces can be for quickly getting test data in or enabling content teams to work in parallel.

The authentication discussion covers built-in integrations with Netlify Identity, Auth0, and Magic Link, along with a private route component in the router. Anthony notes that role-based access control has recently been added as well. Drew reflects on how authentication has become too complex and security-sensitive for most teams to implement from scratch, making these pre-built integrations especially valuable for production applications.

00:33:34 - Maturity, Community, and the Road to 1.0

Drew asks whether Redwood is production-ready, and Anthony points to several apps already running in production, including a COVID data visualization tool and Repeater.dev. He clarifies that despite being announced in March 2020, the framework had already been in development for about a year and is architecturally stable, with version upgrades being additive rather than breaking.

The community discussion reveals a welcoming and well-funded open source project with four full-time team members and active community participation. Anthony shares his own experience being welcomed as a boot camp student making documentation and content contributions. A recently published roadmap to version 1.0 outlines remaining work and invites community help, with a target of reaching 1.0 by year's end.

00:39:32 - Use Cases, Modularity, and Getting Started

Anthony describes Redwood's sweet spot as multi-client applications where a web front end may eventually be joined by a mobile client, thanks to GraphQL's flexibility. Despite being a fully integrated framework, Anthony found through his FaunaDB proof-of-concept that Redwood is more modular than it appears — components can be swapped out without breaking the whole system.

The episode wraps up with advice for getting started. Anthony recommends Redwood's official tutorial, which follows a "tutorial-driven development" approach where the framework was designed to make the learning process intuitive and progressive. He also points listeners to his own 12-part blog series as a companion resource. Both Drew and Anthony express enthusiasm about Redwood's potential to reshape how developers think about full-stack JavaScript application development.

Transcript

00:00:00 - Intro/ad VO

Smashing. Give everyone the best possible start to the day. See special packs for details. It's smashing.

00:00:22 - Drew McLellan

In this episode of Smashing Podcast, we're talking about RedwoodJS. What exactly does it mean to be a full stack Jamstack framework? We talked to community champion Anthony Campolo to find out.

But first, did you know that Smashing Magazine publishes a brand new article to the website five days a week? That's a lot to keep up with, but we're here to help.

00:00:41 - Intro/ad VO

It's your weekly update.

00:00:53 - Drew McLellan

In an introduction to running Lighthouse programmatically, Katie Bowman takes a look at some of the advantages that running Google's Lighthouse analysis suite programmatically can bring to larger and more complex web applications. Using Lighthouse programmatically allows engineers to set up quality monitoring for sites that need more customization than straightforward applications allow. Kate gives a brief introduction to Lighthouse, discusses the advantages of running it programmatically, and walks us through some basic configuration.

Blessing Sophia helps us create more engaging interfaces by animating React components with GreenSock. The GreenSock Animation Platform is a set of JavaScript functions that let you tween a value, attribute, or CSS property over time and insert these tweens into a timeline, allowing for more complex animations. In this article, Blessing explains how GreenSock plays well with the React library by integrating its functions into a React component and building an example landing page with a variety of animations.

00:01:51 - Weekly-update/stinger voice

Yes.

00:01:58 - Drew McLellan

In designing for attention, Victor Yoko covers specific tactics with supporting research that are bound to help you design for attention. He also discusses the need to understand why we want to gain the user's attention, as well as what our user's needs are.

00:02:14 - Weekly-update/stinger voice

Oh yeah.

00:02:16 - Drew McLellan

In advanced GraphQL usage in Gatsby websites, Aleem Isiaka explains what GraphQL query constructs are and how they can be used to interact with the data access layer over a Gatsby website. Aleem takes a look at some of the advanced use cases of GraphQL within a Gatsby website by using matching data from different sources.

Adebiyi Adedotun looks at how to integrate different CSS-in-JS methods. In comparing styling methods in Next.js, tools like Next have a simple goal of abstracting away commonly redundant tasks when writing a React app. While this is usually a good thing, it does require you to learn and understand the different ways to use that abstraction. Using CSS with Next is one such case, and this tutorial covers all your options.

And that is your weekly update.

00:03:09 - Intro/ad VO

Find all these and more at Smashing Magazine.com.

00:03:17 - Drew McLellan

He's a Lambda School student studying full stack web development, as well as being a contributor to RedwoodJS, something of a community champion. He's recently written a 12-part article series called A First Look at RedwoodJS that helps to explain the origins and motivations of Redwood, along with many of the different concepts that the framework introduces. So we know he's an expert at RedwoodJS, but did you know he's never seen a dog? My Smashing friends, please welcome Anthony Campolo. Hi, Anthony, how are you?

00:03:43 - Anthony Campolo

Hello, I am smashing. Thank you so much for having me.

00:03:46 - Drew McLellan

I wanted to talk to you today, and it's probably obvious from the introduction, about RedwoodJS. For those who haven't heard of RedwoodJS before, at a high level, what is it?

00:03:58 - Anthony Campolo

I think there are a couple ways you can describe it, kind of depending on where people are coming from. The canonical definition is that it's a full stack serverless framework for the Jamstack. So it combines full stack web development with serverless, like AWS Lambda type stuff, and the Jamstack, which is a big thing these days.

00:04:22 - Drew McLellan

So it's a full stack framework that tries to put together lots of the ideas around a Jamstack development ecosystem. Is that right?

00:04:32 - Anthony Campolo

Yeah. It's pushing the boundaries of what a Jamstack application can be. By calling it full stack Jamstack, it's about how do we go beyond just the front end to having the same sort of deployment paradigm of just getting your whole code deployed. How do we get that, but also with our backend, and have it all connected?

00:04:52 - Drew McLellan

Now, before we delve too deeply into it, I think it's quite interesting to hear that it's from quite a seasoned team, isn't it? The people behind Redwood, they're not spring chickens. Not to say they're old, but they've been around the block, haven't they? In terms of web development, they're seasoned.

00:05:11 - Anthony Campolo

Yeah, I've actually put a decent amount of time into writing about the history of the framework and the ideas that have kind of led to it. Tom Preston-Werner is the creator, and so he's also known as the creator of Jekyll, which is a really influential static site generator. He also did the TOML configuration file language, and he was the CEO of GitHub originally. So his work with Jekyll and GitHub Pages and that sort of thing, I think, has really led to what we now think of as the Jamstack.

A lot of people would say, "Oh, the Jamstack is not new. They've been doing this forever," and that's kind of what they're talking about. It's an extension of these older ideas of static site generators, but with GraphQL and serverless and these ideas of how to use glue code and APIs to make your app work.

00:06:03 - Drew McLellan

So this is definitely from people who are very embedded in that community. I mean, the CEO of GitHub, you really don't get more embedded in the open source community than that. So Redwood is a full stack framework, and that means you've got Redwood code running in the front end and in the back end. Is that right?

00:06:24 - Anthony Campolo

Yeah. This is the first thing I like to explain to people when I'm showing them a Redwood project, is that it's a monorepo. So you have your front end and your back end in the same repo, and each of those lives in its own folder. You have a web folder, which is your front end, and it's fairly similar to what you'd get from a Create React App. Then you have an API folder, which is your back end. This is where all of your functions get essentially shoved into one big GraphQL handler that gets deployed to AWS Lambda through Netlify.

00:07:00 - Drew McLellan

Okay, so starting at the front, as you mentioned, it's based around React. Is that React plus a bunch of Redwood code, or is it just plain React, or what's the balance there?

00:07:11 - Anthony Campolo

It's a lot of things. It's definitely just React in the sense that you're not bringing in a lot of state management libraries. You're not even bringing in a router. Actually, they have their own router that they wrote, and they use a lot of GraphQL stuff. So when people talk about React and GraphQL and friends, that's a bit of what's going on here. It gives you a lot of default integrations to get React talking to your GraphQL, because we have a lot of conventions now over how to use React, but the data fetching is still a huge hassle.

00:07:47 - Drew McLellan

So it's React configured with a bunch of other tools that work nicely with React to give you a functioning ecosystem for doing this particular style of task. Is that a fair description?

00:07:59 - Anthony Campolo

Yeah, that's a great way to put it. The way Tom has put it is that there are all these best-of-breed solutions that exist and really sophisticated tools and technology we can use, but it's really hard to actually leverage them because you have such a huge startup cost of having to learn them and figure out how to integrate them. And so they set the tagline as, "We do your Webpack config for you."

00:08:24 - Drew McLellan

I think it's a common pain point that you hear from lots of people when they're trying to get started in the modern development framework with client-side JavaScript apps and configuring Webpack, configuring all the different things, the build processes, the build steps. It can be quite a minefield, can't it, to get everything hooked together and working. And it's a long way before you get to hello world. So Redwood is giving us all that pre-configured.

00:08:52 - Anthony Campolo

Yeah, it's very much a convention-over-configuration type idea. Tom built GitHub with Ruby on Rails, and Rob, one of the other core contributors, has been a Rails developer forever. So they have a lot of ideas that they philosophically align with in terms of Rails, but they want to take those convention-over-configuration ideas, the full stack framework ideas, and implement that with all the modern technology we have now.

00:09:19 - Drew McLellan

So you mentioned that Redwood gives you a router, as we say over on this side of the pond. Does it come with things like default components and any of that sort of stuff in React, or are you then to implement all that yourself?

00:09:33 - Anthony Campolo

The router is very sophisticated. It does most of the stuff that you would get from React Router. It has different ideas in terms of how these should be implemented, because Next also has its own router. And it's still not really entirely figured out how we want to get our single-page app routing to work. Because of Suspense, you have a lot of these questions over where the async stuff is going to come in. With Redwood, we have this idea of a cell, and this is what really does your data fetching for you.

00:10:08 - Drew McLellan

Okay. Maybe we could go into that a little bit. What is a cell in terms of Redwood?

00:10:14 - Anthony Campolo

A cell is a default way to write a GraphQL query and then have your page basically tell whether you're getting the data back, whether you're getting an error back, whether you're in a loading state, or whether there's a fourth state, I forget. It gives you the different states that you can be in based on whether you are getting your data or not.

It's set up with Apollo under the covers. So if you're using Redwood, you're using Apollo as your GraphQL client, but you don't ever have to think about it. You never have to actually write any Apollo or even think about it. It's all baked in. So it lets you just write GraphQL queries, which was really the dream of why people wanted GraphQL. It was like this really simple query language that front end devs could use, but then you had to figure out how to set up a GraphQL server. You had to figure out, like, am I using all this other stuff, and how do you get that all wired up?

00:11:14 - Anthony Campolo

So it does all of the GraphQL integration kind of for you. You can just write GraphQL. You don't have to think about how do I even implement GraphQL.

00:11:22 - Drew McLellan

So I guess one of the classic jobs of a framework is to take all the boilerplate code that you could write yourself and implement it for you, and tidy it away behind the scenes so you never have to look at that boilerplate ever again. You can just write the code that's unique to your circumstance. I guess that's what's going on with a cell, is it?

There's nothing revolutionary here. It's something that you could set up a React component to have all these different states, and you could hook in Apollo and you could do all this yourself. But that's actually quite a lot of work, and it's a common pattern. Redwood has tidied it up into a nice reusable pattern that you can just start using without having to think about it. Is that a good description?

00:12:09 - Anthony Campolo

Yeah, they came up with the name, but they definitely acknowledged that this was a practice they saw frequently and that they saw a lot of people just coding up themselves. They decided that they wanted a declarative way to do your data fetching. That's why you have this setup, because it lets you just have your different states and you don't have to do if-then logic to figure out how you need to do this if this happens. It's about having a single way to declare all the different states your data could be in as you're loading it.

00:12:39 - Drew McLellan

It's one of the characteristics of React, isn't it, that React doesn't try to give you an architecture for your project. It lets you decide how you're going to structure things, and that of course has pros and cons. But it seems like Redwood is imposing some of that structure for you so that you don't have to think about it, and so that it can put the plumbing in for you and pick up where React left off in terms of giving you that structure.

00:13:05 - Anthony Campolo

Yeah. And I think it's really interesting that we've seen multiple different attempts at this solution to this problem. You've had people who've been saying forever, like, why isn't there a Rails for JavaScript or Rails for React? There's a great Full Stack Radio interview between Michael Chan and Adam Wathan called "React Is Not a Rails Competitor." This is one of the different frameworks. The other one is Blitz.js, which has gotten a decent amount of buzz. And then Bison is kind of a new up-and-coming one.

They all have a similar stack, but they use different pieces. You'll have React Query instead of Apollo, or you'll have Chakra instead of Tailwind. So there are people who are putting together all these pieces into their own stacks. All these stacks are kind of battling it out. It's all very friendly competition. And actually, that's one of things that I really appreciate, is that we all collaborate between the frameworks as well.

00:13:59 - Anthony Campolo

There's no animosity there.

00:14:01 - Drew McLellan

So we've mentioned Apollo and GraphQL. Redwood uses GraphQL quite heavily. It's one of the core pieces of the framework. We could probably dedicate an entire podcast episode to just GraphQL, but for those who aren't familiar, what is GraphQL doing here? What problem is it solving in this context?

00:14:22 - Anthony Campolo

Yeah, this is a great question. When I am telling people what they should know to have a good start with Redwood, I'd say that you should have used Create React App. If you've made a Create React App and you've deployed it to Netlify or Vercel, that will get you a good start. And then know at least a little bit of GraphQL because it is very central.

The GraphQL is how your front end will talk to your back end. They say it's a query language for APIs. The idea is that it's meant to be an alternative to RESTful APIs, which have your GET, POST, PUT kind of methods. Instead of doing that RESTful thing, you are sending queries which specify exactly the hierarchical data structure you want to receive back from the database.

So it requires a little more startup time to get your GraphQL server to talk to the two pieces, but then once you have it there, the front end developers have the ability to get data in a much more flexible way. You don't need all these different API endpoints that your backend guys need to keep making.

00:15:30 - Drew McLellan

And so if there are changes in requirements in the front end, presumably you can then just tweak your GraphQL query, and you don't need the help of somebody who works on the back end to make that change for you.

00:15:40 - Anthony Campolo

I mean, the real dream is you could throw on a mobile client, that it would be that flexible. Ultimately, you can have multiple clients all talking to your one API. Your GraphQL API becomes your source of truth, and that's where all your logic is centralized. Then you can build all these different view layers on top.

00:16:01 - Drew McLellan

So we've got GraphQL there, giving us the ability to query some sort of backend in Redwood. What is the back end?

00:16:10 - Anthony Campolo

There are a couple different ways to create your back end. There's the way you'll get out of the box with the tutorial, which is you use a Postgres database deployed on Heroku. Super easy, super simple. Then your Redwood app talks to it with Prisma. I don't know if you're familiar with Prisma, but it's kind of like an ORM. They specifically say it's not an ORM, it's a query builder, which is a little lower level. But for the sake of just explaining it to people, Prisma is the thing that lets you talk to your database. It does your migrations, sets up your tables, and does all the SQL stuff so you don't have to write SQL. To me that sounds like an ORM.

You don't necessarily need to use Prisma to use Redwood. I actually built a proof-of-concept app where we used FaunaDB instead. FaunaDB has its own GraphQL API, so you can just send GraphQL straight to Fauna and then do your database mutations that way. So you lose a lot of the functionality of Prisma CLI.

Prisma is really a convenience factor to work really easily with your relational database, but you could hook up anything you could think of with Redwood, is what I found out. It's built around GraphQL, and the whole point is to be able to talk to all these different pieces.

00:17:39 - Drew McLellan

So Prisma is essentially an abstraction layer between your code and whatever data store that you're using, presumably that Prisma supports. Is that, or is it doing more intelligent things than that?

00:17:54 - Anthony Campolo

Yeah. So you write a schema. You create a schema.prisma file, and it would have, like, model post, then it would have id and integer and autoincrement, like title string, body string, createdAt datetime. You create what you want to be in your database with the types, and then it does the database stuff for you so you don't have to interact with the database.

00:18:17 - Drew McLellan

So you use Prisma to define what sort of database or data store that you're talking to, and then you lay out your different models, to use that parlance. So when your application is talking to the data store, it's kind of using an instance of a Prisma client. Is that what's going on?

00:18:41 - Anthony Campolo

Yeah, that's exactly it. In your back end API folder you have a lib folder with a db.js, and by default that has your Prisma client set up. That's all the stuff you get out of the box. And like you said, Prisma can work with different databases. It can switch between SQLite for development and then Postgres for production, that kind of thing. It's mostly relational ones right now, but the roadmap has things like Mongo and Fauna on it.

00:19:10 - Drew McLellan

So that's quite useful. If you can set up and use SQLite in your local development environment as you're getting things up and running, and then go into production with something like MySQL.

00:19:22 - Anthony Campolo

Yeah, that's exactly how the tutorial is set up. That's the workflow it shows you.

00:19:26 - Drew McLellan

It's quite interesting to see a very modern approach to a framework then falling back on some of these more traditional databases like MySQL. I'm very familiar with MySQL, and I love it for its stability, and I love the relational way of storing data. I think it works so well for so many things. Often you see the baby thrown out with the bathwater when it comes to the newer types of data store. So it's quite interesting to see Redwood, by default, supporting these good old relational databases.

00:19:59 - Anthony Campolo

Yeah, that's such a good point, because I say that for all the new stuff Redwood combines together, there are some things that it actually says the old tried-and-true way is the best. They are really big on relational databases, and that comes from Tom's experience using Rails and having a relational backend. Active Record was the ORM layer that Prisma is meant to approximate.

00:20:26 - Drew McLellan

I guess we're talking about a serverless architecture here with Redwood. We talked to Chris Coyier, I think two or three episodes back, all about serverless using APIs and cloud functions and things. So taking a step back, if you were to think in terms of a server-based framework like Ruby on Rails or something like Laravel in the PHP world, even with a React front end, your API requests would be running code that is Rails code or Laravel code plus your user code and configuration. Is that the same with Redwood? Is there actual Redwood server code that runs, or is it just more tools and structure and glue that enables you to implement your own?

00:21:08 - Anthony Campolo

Yeah. So in the back end, there's a file specifically that is a way to take your SDL. You have your schema definition language, and then you have what are called your services, which are kind of like your methods for talking to your back end. All of this gets stitched together into a GraphQL handler that is deployed to a single Lambda function. So it's optimized for Lambda specifically.

We actually just recently had someone do it with the Serverless Framework, and we've got some people working on Azure and Google Cloud, not Google Cloud Functions, the one built on top of that. But yeah, so it's right now basically optimized for deploying your backend as a GraphQL function in an AWS Lambda. This is the stuff that's all magic happening in the codebase. I don't understand it, but that's the high-level explanation.

00:22:09 - Drew McLellan

So there are deployment tools out there that take all the code that you've written, squash it all together into some sort of magic ball of code that can be executed in the cloud, and put it up onto AWS. Or do you still have to manage that process yourself?

00:22:23 - Anthony Campolo

Yeah. So it's all done through Netlify if you follow along with the tutorial. You don't really have to mess with any sort of serverless functions yourself, and the stuff that wires your back end together to shove it into AWS Lambda, that's all handled. You don't have to touch any of that code. That's kind of all generated out of the box as your conventions over your configurations. So you don't really have to think too much about how to make it serverless. It's serverless by default. That's a really hard thing to wrap your head around. It took a while for me to wrap my head around it.

00:22:55 - Drew McLellan

Yeah, because it's an important point, isn't it? There are actually now quite a few different areas we're keeping track of here. We've got our front end React app that's running in the browser. Then we've got an API that is GraphQL-based running as a cloud function, and that's responding to our queries. But that's then interacting with the data store which uses Prisma. And that data store is what and where in this, because you can't run a MySQL server on Netlify, can you?

00:23:31 - Anthony Campolo

Yes. That's where Heroku comes in. So in the very last part of the tutorial, you deploy your front end to Netlify and then you deploy your backend to Heroku Postgres. You just grab your config variables from Heroku, plug it into Netlify. So getting your Netlify front end to talk to your Heroku Postgres backend is a really, really simple thing.

They wanted to go with the thing that was going to be the easiest for anyone to get spun up, but still have good, stable, battle-tested tech. At the end, what you get out of the box just by following the instructions is really incredible.

00:24:06 - Drew McLellan

Jamstack enthusiasts will be familiar with services like FaunaDB that you mentioned that provide a data store as an API. AWS has DynamoDB, Google's got Cloud SQL, and so on. You mentioned that Redwood is looking at integrating, or I guess Prisma is the component here, that's looking at integrating with those sorts of services further down the line.

00:24:29 - Anthony Campolo

Yeah. This is a good question. This is something I'm actually talking with Ryan Chenkie at Prisma about, kind of helping out with, is what is the database story for Redwood, for things that don't necessarily work with Prisma. Would it be better to figure out a way to get Redwood to work with it directly, like I did with Fauna, or would it make more sense to implement a driver for Prisma? So there are different ways to approach it, and there are obviously a million different databases now that everyone wants to use. So it's kind of how motivated are you to get your data store onto it, and there's a lot of community contributions going in there.

00:25:07 - Drew McLellan

So because Prisma understands your models and it knows how to query them, it's able to generate some sort of migrations or things like that to help you get that database set up.

00:25:15 - Anthony Campolo

That's exactly the thing that you lose out on when you have to take Prisma out and get your database. You lose all the migration functions. It has a really advanced CLI that does a ton of stuff for you. You can go through the whole Redwood tutorial and enter the Prisma commands, and you don't have to have any idea what it's doing. It just kind of works. It's a really great tool for doing all that database type stuff that you want to make sure you get right and you want to make sure it's done correctly.

00:25:43 - Drew McLellan

It seems like having really good tooling around frameworks is quite a modern trend. Not just saying, here's all the things that this framework can do, but here's some CLI tools that are going to do a whole bunch of it for you. Does Redwood have tools for things like CLI generators and stuff to get you up and running quickly?

00:26:09 - Anthony Campolo

Yeah, this is probably the biggest key feature that you get from Redwood. You get a whole set of very sophisticated generators. For anyone who's ever seen the original Ruby on Rails demo that DHH gave, where he builds a blog in like 15 minutes and does it all with Rails, people are like, "Whoa, this is amazing." That's kind of the effect Redwood is going with. They want you to be able to get everything spun up really quickly so you can generate pages, you can generate layouts, you can generate your cells, which I was talking about. You can do a scaffold command that is going to create your entire CRUD interface.

I have a whole section, part four of the blog series, just explaining all the code that the scaffold gives you. It gives you so much code. There's an auth generator. There's even a Tailwind generator that configures your Tailwind for you.

00:27:02 - Drew McLellan

That's amazing. I remember seeing DHH's demo of Rails. It was probably, what, 15 years ago now, when he first did that scaffolding and showed you. You get a fairly rudimentary but functional control panel, essentially, to enable you to create new items, edit them, delete them, etc. That can be invaluable in a project, especially working in a dynamic environment where maybe you're going to implement better tools in the future for editing that content, but it means being able to spin something up quickly. You can get test data in, or you can even hand that over to a content team who could start working whilst you're working on the front end.

So that's really useful. But if you wanted to just deploy that and have that in production, presumably you can just deploy it along with your front end code, but you'd need some way to secure that aspect of those routes in your application.

00:28:00 - Anthony Campolo

Yeah, there are a couple different options for authentication. You can use Netlify Identity, that's the default if you go to the tutorial. Then you can also use Auth0, and then one I'm not familiar with called Magic Link. There will probably be a couple extra ones added in the future, but yeah, there are a couple built-in solutions there for you already.

That's the very last thing you do. The very last part of my whole 12-part blog series is the auth one. I don't think I'd ever figured out auth before I'd used Redwood. It's hard, and they definitely have done a good job with it.

00:28:38 - Drew McLellan

And does that integrate at a route level? Or how do you secure things?

00:28:46 - Anthony Campolo

Yeah. So part of how they have their own router, they also have private routes. They have a private route component. Then your actual login form, that's what you get from Netlify Identity. So you don't have to actually create your form and do your state management with that. That is where a lot of problems come into play.

Just taking away the really key parts, and then you can implement role-based access. We have role-based access control add-on that has been done over the last couple of weeks by David T. So there's a lot of work happening to create other ways to do it. But what they've got now already works. It'll get you there.

00:29:26 - Drew McLellan

Functional people always say about security algorithms, hashing, cryptography, that you should never write your own because it's never going to be as good as the things that are out there. Increasingly, I think that's also true of authentication. At a higher level, authentication is such a complex area these days where people want to not just log into your site with unique credentials, but they might want to authenticate using Google, or they might want to authenticate using an Apple device, or they might want two-factor authentication. They might want to integrate it with their single sign-on service that they're using from an enterprise.

All these things are such a headache if you try and implement it yourself, and there's so much opportunity for getting something wrong and exposing security holes in your application, that using an authentication service seems like almost a no-brainer at this point to me. So just being able to drop something in with a few lines of code and be up and running sounds like a really productive way to work and to keep things secure.

00:30:39 - Drew McLellan

It sounds like deploying both the front end and the server aspects, the serverless functions things, is a natural fit for deploying to Netlify. Are you tied into that with Redwood? We mentioned that Tom Preston-Werner is one of the main proponents of this framework. He's also on the board at Netlify. Do you think there's potential for tighter coupling there if you were to choose Redwood as the basis for a project?

00:31:11 - Anthony Campolo

Yeah. This is something that Tom's definitely conscious of. He's invested in a lot of companies that float around. He invested in Prisma and Fauna, and he wants to make the tools he wants to use. So it's not about, like, we want to lock you into this thing. It's more like what Netlify has built, he thinks, is the best option, so that's why they built around it. But they don't want it to be locked into any one deployment target.

That's why we have work being done on things like the Serverless Framework, and some people have talked about Begin. We want this to be pragmatic. We want it to work for whatever someone's use case is. We get you 90% of the way, and then you just have to wire up the last couple things to get it to work with whatever your service of choice is.

00:31:56 - Drew McLellan

I guess even Netlify is using AWS Lambda for the serverless functions. So it's really the deploy part that's taken care of by Redwood there. And actually, you could deploy that to Lambda yourself. Hosting your front end is just files, isn't it? It's CDN-based, the rest of it. So there is quite a lot of flexibility there without being too tied in.

00:32:21 - Anthony Campolo

Yeah. There's actually a term that Tom talks a lot about as the core philosophical idea behind Redwood, which is that we want to get to a universal deployment machine. The idea is that you can just deploy things and you don't have to think about it at all. He's been talking about this idea for years and years and years. This is kind of what Jekyll was even about back in the day.

When you hear that now, you're like, "Oh, you mean Netlify?" That's basically what Netlify is to most people who are working on the front end. They don't even think about deploying anymore. It's not even a thought.

00:32:54 - Drew McLellan

Yeah. Here's my application in a Git repo. This directory is the front end, this directory is the back end, here's my database. And that's about as much configuration as perhaps you would need for them, whatever service, to take it and to build it and host it.

00:33:10 - Anthony Campolo

Yeah. And one thing I should also point out, we just very recently got a Vercel Redwood default deploy setup. When you're deploying on a service like that, you can say, "Oh, I have a Gatsby app," and it knows exactly how to build a Gatsby app versus a Next app. So we have that for Vercel now. There are really, really good non-Netlify options as well if you're more into that.

00:33:34 - Drew McLellan

So if I wanted to get started and build an app and take it into production like this week, is Redwood ready for that? Is it mature?

00:33:42 - Anthony Campolo

Yeah. We've got about a half dozen apps in production right now. The first one was called Predict COVID, which came out back in March, and it was a real-time data visualization application. Then we've got Repeater.dev, which is done by Rob. It's like a kind of a cron job-like thing for Jamstack. And then there's another one. So there's at least a handful. If you go to the Awesome Redwood repo, you can see a list of all of them, and if you go to the community forums you can find write-ups of these as well. People have put these into production and then kind of said how it went so far. They've all been successful. And no one said, "I'm never using this again."

00:34:29 - Drew McLellan

But it is very new. I guess there's no escaping that in terms of maturity. Redwood's pretty new. It's getting a good following.

00:34:37 - Anthony Campolo

Well, it's funny, it isn't. It was announced in March. At that point, it had been worked on for about a year by Tom and Peter. So they had already put a ton of upfront work into this. It wasn't like, I'm going to announce this project with a README and then start building it. By the time they announced it, it's not at 1.0 now, but it's pretty dang close in terms of what people would expect out of 1.0.

Tom's very against what he calls hype-driven development, so he always errs on the side of, "It's not ready." We say it's not ready for production even though it's in production.

00:35:13 - Drew McLellan

I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework, and then that framework will very quickly go to another major version that has backwards incompatibilities. Then they're left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

00:35:47 - Anthony Campolo

Yeah, it's definitely a super valid concern and definitely something the team has thought about. The CLI has an upgrade command. So you can basically, every time there's a version bump, you just do a command and it bumps you up the version.

I've been dealing with this a little bit just because of the series I wrote. I started it when it was on version 0.11. It's like 0.17 or something now. So I've kind of been slowly iterating on it as it's gone, but nothing breaks. It's all additive things like, "Oh, this is kind of a nice little touch you got here." It's very much set in stone architecturally. Redwood, as it's structured for the back end, is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they can get something that was structured like this thing.

00:36:37 - Drew McLellan

I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

00:36:53 - Anthony Campolo

So it's exactly why Tom invented semantic versioning.

00:36:57 - Drew McLellan

I guess, from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, you know, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that?

00:37:20 - Anthony Campolo

Well, some would say that a redwood tree can survive a lot and last for a very long time. So that may have been why it's called that, is that you can just make a site and deploy it and it's not going to break. It's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. And being built by people who tried to scale Rails apps, I imagine they've thought a lot about that.

But in terms of the going-away part, that's always going to be a danger of any open source project. So I think you have to look for how enthusiastic the community is to continue it without the team if that ever happened. I don't think you even need to worry about that, because Tom's a billionaire and he has a venture funding thing that is funding some of the development. So it is an open source project that is well funded, actually. It has four full-time members: Tom, Rob, David, and Peter. You just go to the forums, you see the activity that's going on. So I wouldn't worry about that too much, of course, beyond normal open source worries that come along with that stuff.

00:38:30 - Drew McLellan

Yeah. And what is the community like? You mentioned the community. There are lots of people using it and contributing to the codebase, or is it mainly the core team who are doing the development?

00:38:40 - Anthony Campolo

Yeah, it's very much structured to be a community thing. They want to get as much buy-in from the community as possible. And this comes from the lineage. Like you said, there's a few people with more open source cred than Tom. He's done a really great job of bringing people into the fold. My story in general is a big win for the community because I came in as a boot camp student. I'm learning all this stuff as I go. I'm not pushing code to the repo. I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value.

So there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

00:39:32 - Drew McLellan

Some frameworks have got the natural bent for certain types of projects. For example, the Python framework Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects it's suited for, content publishing or building web applications?

00:39:56 - Anthony Campolo

It's made to be fairly agnostic to that. It wants to be a tool that you can use for a lot of stuff. Before it was called Redwood, it was called Hammer, the idea being that you can do a lot of stuff with a hammer. But there definitely is a sweet spot, which I think is the multi-client type applications. So if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So I would say that would probably be the first thing I would say is its sweet spot, but it's meant to work for as many things as possible.

00:40:41 - Drew McLellan

Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

00:40:49 - Anthony Campolo

Glad you asked. We just put out a roadmap to 1.0 less than a month ago. It was probably like two or three weeks ago. It itemizes things that we're working on, things we think we're kind of close on, and things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things that are really great about it: showing, like, here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. So we'll see where we get with that, but that's the trajectory we're currently on.

00:41:25 - Drew McLellan

One of the beauties of a Jamstack and serverless approach, I think, is this idea of lots of pieces loosely joined. That has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends, or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces.

Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? I mean, could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

00:42:14 - Anthony Campolo

This is something I think about a lot. As I learned web development, I was in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the stack, but we learn React, and then we learn Express, and we never talked about how they actually work together. So I do think that there's definitely a danger of not being able to comprehend your project because of how it's all wired up.

What I really liked about Redwood is that it made sense. It was a mental model of how to think about my entire app and all the pieces, and how they fit together in a way that really made sense to me. But what I was surprised to find doing the Fauna project is that it's much more modular than you would think. Like you said, it sounds like it's a monolith thing, but you can pull pieces out and replace them with other pieces, and it can still kind of work.

00:43:12 - Anthony Campolo

So it's made to be a fully integrated solution, but not a solution that is tightly coupled. Just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them.

00:43:25 - Drew McLellan

Well, yeah. That sounds very promising. It would be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

00:43:39 - Anthony Campolo

No. I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they've called tutorial-driven development, which is kind of a play on README-driven development, which is another thing Tom coined. You should start with your README and then create your code to make sense with what your README was. The idea is that you create a tutorial and then you write your framework to make the tutorial work.

That's why it is a really easy way to get spun up with it, because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech, and they progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially build the same project, but I kind of write my own stuff as I go and reference the docs.

If you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

00:44:43 - Drew McLellan

So I've been learning all about Redwood. What have you been learning about?

00:44:47 - Anthony Campolo

Yeah, so I've been learning about CMSes, and I was actually really curious to get your thoughts on this, because I imagine you've been around the block with a lot of CMSes. Obviously, you've got your WordPress, your Drupal. But what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, the headless CMS is just such a natural fit.

So I'm trying to figure out what are interesting headless CMSes to check out, which ones have GraphQL integration, which ones have different kind of sweet spots. So if I wanted to pick a CMS to build an app with RedwoodJS, what would you recommend?

00:45:21 - Drew McLellan

That is a good question, and I'm not sure. I have looked at lots of different CMSes, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not...

00:45:36 - Anthony Campolo

Oh man, you got it. You got it. Join the club, dude.

00:45:39 - Drew McLellan

Yeah, no, I'm definitely getting on board. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL. So it's certainly one of the things that I need to be learning.

00:45:50 - Anthony Campolo

I actually learned GraphQL through Redwood. I didn't really know GraphQL. And I say you should know a little bit before going into it, and I had a very, very tiny, tiny basic knowledge. But you can actually learn what a schema definition language is and that GraphQL jargon. You'll pick up a lot of that stuff as you go with Redwood.

00:46:08 - Drew McLellan

Yeah, I should definitely get on board, and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me?

00:46:21 - Anthony Campolo

Yeah. At the very least, I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

00:46:34 - Drew McLellan

If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. Do you have any parting words?

00:46:54 - Anthony Campolo

Just if you're interested in any of this stuff, feel free to reach out. My DMs are always open. The community is very open in general. I'd be happy to explain or walk through or get you set up with anything you need to know to get going.

00:47:08 - Intro/ad VO

This is smashing.

00:47:11 - Drew McLellan

And that was our podcast. Thank you very much for listening. And if you liked it, please share it with your friends.

00:47:16 - Intro/ad VO

Find us on the web at Smashing Magazine.com, on Twitter, at Smashing Magazine, on Facebook, or in the supermarket by the cat food.