RedwoodJS with RedwoodJS Core Advocate

Episode Description

Jason Swett interviews RedwoodJS core advocate Anthony Campolo about the full-stack JavaScript framework built by GitHub co-founder Tom Preston-Werner.

Episode Summary

In this episode, Jason Swett sits down with Anthony Campolo, a core advocate for RedwoodJS, to explore what the framework is and why it matters—even for Rails developers. Anthony explains that RedwoodJS is a full-stack JavaScript framework combining React, GraphQL, and Prisma (a next-generation ORM comparable to ActiveRecord) into a convention-over-configuration package created by Tom Preston-Werner, co-founder of GitHub. The conversation traces the architecture of a Redwood project—a monorepo split into web and API folders—and examines how the framework defaults to serverless deployment by bundling the entire back end into a single AWS Lambda rather than splitting it into microservices. Jason and Anthony discuss the framework's tutorial-driven development philosophy, where the tutorial was written before the framework itself, and compare it to Rails' ecosystem, including its reliance on Michael Hartl's tutorial. They also touch on Prisma's evolution in the Node ORM landscape, the shift away from MongoDB as the default data store, and the broader value of looking beyond one's own development ecosystem to gain perspective on conventions and trade-offs.

Chapters

00:00:00 - Introduction and What Is RedwoodJS

Jason opens the episode with a brief sponsor message before welcoming Anthony Campolo, a RedwoodJS core advocate who has been following the podcast despite not being a Rails developer. After some friendly banter, Jason asks Anthony to explain what RedwoodJS is for someone unfamiliar with it.

Anthony describes RedwoodJS as a full-stack JavaScript framework that combines React, GraphQL, and Prisma with a relational database. He emphasizes that it follows a convention-over-configuration, opinionated philosophy similar to Rails. The conversation then turns to Prisma, which Anthony explains is essentially the JavaScript equivalent of ActiveRecord—an ORM that defines schemas and maps objects to relational databases like Postgres, MySQL, or SQLite.

00:05:39 - Project Structure and the Rails Connection

Jason asks about what sits between the React front end and the Prisma ORM, prompting Anthony to explain the Redwood project structure as a monorepo with two main folders: a web folder (comparable to a Create React App setup) and an API folder that itself splits into Prisma and GraphQL components. Jason then pauses to explain to listeners why he's covering a JavaScript framework on a Rails podcast, using the "what is water" parable to argue for cross-ecosystem awareness.

Anthony pushes back on the idea that RedwoodJS has nothing to do with Rails, noting that creator Tom Preston-Werner built GitHub with Rails and later used a React-plus-GraphQL-to-Rails architecture at his company Chatterbug. Jason acknowledges this connection but takes a moment to caution junior developers against concluding that Rails can't scale, noting that GitHub-level scale is an extreme edge case most applications will never encounter.

00:12:19 - Serverless by Default and Deployment

The conversation shifts to one of Redwood's key philosophies: being serverless by default. Anthony explains that serverless computing, built on AWS Lambdas, uses an event-driven model where you only pay for actual function invocations rather than maintaining always-on servers. He clarifies that Redwood doesn't advocate for microservices—instead, the entire back end gets packaged into a single Lambda function as a monolith.

Jason expresses relief at hearing this, having initially worried that the approach implied microservices from day one. Anthony then walks through the canonical deployment path: the React front end goes to Netlify while the database lives on Heroku Postgres, connected through environment variables. Jason asks what Netlify is, and Anthony describes it as a supercharged version of GitHub Pages designed for the Jamstack ecosystem.

00:19:08 - Tutorial-Driven Development and the Redwood Tutorial

Anthony introduces one of Redwood's distinctive contributions: tutorial-driven development, where the official tutorial was written before the framework and continues to guide its evolution. Jason notes how this contrasts with Rails, which relies on Michael Hartl's community-created tutorial rather than an official one. Anthony explains that the tutorial introduces concepts sequentially—React first, then Prisma, then GraphQL, then deployment—so learners aren't overwhelmed by the full stack all at once.

Anthony shares his personal experience of learning Redwood through the tutorial while attending a web bootcamp, finding it far more coherent than trying to wire together React, Express, and Redux manually. He then walks through the tutorial's Prisma section, where users define a Post model, run migration commands, and use the scaffold command to generate a full CRUD interface, all starting with SQLite in development.

00:24:50 - Prisma Deep Dive and the ORM Landscape

Jason recalls his brief foray into Node and Express development around 2014–2015, when the ORM landscape was immature and nothing approached Rails' ActiveRecord. Anthony confirms that the ecosystem has matured significantly, pointing to Sequelize and TypeORM alongside Prisma as sophisticated options. He explains that Prisma's "next generation" claim stems from its planned ability to work with both relational and document databases, and breaks down its two main components: Prisma Client for data access and Prisma Migrate for schema migrations.

The discussion broadens into the MongoDB versus PostgreSQL debate. Anthony notes that many JavaScript developers default to the MERN or MEAN stack without fully understanding what they lose by skipping relational databases. Redwood takes a firm stance by being relational-only through Prisma, though Mongo support is on the roadmap. Jason shares his frustration with uninformed technology choices, comparing the Mongo trend to the current service-objects pattern in Rails, and both agree that Redwood's approach of pairing cutting-edge front-end tools with battle-tested relational databases strikes a healthy balance.

00:30:11 - Code Distribution, Flexibility, and Wrap-Up

Jason asks where the bulk of code lives in a Redwood project. Anthony explains that it depends on the application—some developers lean heavily on the API side and swap in Next.js for the front end, while others build out elaborate React interfaces with minimal back-end logic. This flexibility allows teams to adopt parts of Redwood that suit their needs.

Jason wraps up by reflecting on the value of exploring technologies outside one's usual ecosystem, noting how the conversation exposed him to tools like Netlify and Prisma. Anthony directs listeners to redwoodjs.com for documentation, the community forum, and Discord, and shares his personal handles across Twitter, GitHub, and dev.to. He encourages anyone interested to contribute, sharing how his own involvement grew from curiosity to a core team role that opened professional doors. The episode ends at 00:33:06.

Transcript

00:00:00 - Jason Swett

Dear listener, before we start today's episode, I want to tell you about a resource I've created that I want to share with you for free. I'll tell you what it is and how to get it.

If you're not already writing tests for your Rails code, you're probably aware that testing can help you ship your work faster and with fewer defects because testing is such an in-demand skill. But since so few developers know how to do it properly, I've created a resource for you called The Beginner's Guide to Rails Testing.

This guide is a short downloadable ebook that answers the most common Rails testing questions that beginners tend to have, including which testing framework should I use, RSpec or Minitest? What level of test coverage should I shoot for? What are the different kinds of Rails tests? What are all the Rails testing tools, and how do I use them?

My guide covers these questions and several others. To get The Beginner's Guide to Rails Testing, go to Rails Testing guide.

Now on to the episode. Hey, today I'm here with Anthony Campolo, RedwoodJS core advocate.

00:01:44 - Jason Swett

Anthony, welcome to the show.

00:01:46 - Anthony Campolo

Hey, thanks for having me, Jason. Really happy to be here. I've been listening to the podcast for a while, and it's going to be cool to talk about some of these ideas. You talk about a lot of things I find very interesting, even though I'm not actually a Rails developer at all. So I'm happy that you've brought me on to the show.

00:02:02 - Jason Swett

Yeah, I'm glad to have you here, and it's nice to hear that you're interested in the things I say. It's nice to have somebody interested in the things that I say. I tell my wife things, both computer stuff and just things in general, and she's generally not very interested. And so at least Anthony's interested. I got one person.

00:02:22 - Anthony Campolo

Yeah. At least one.

00:02:25 - Jason Swett

Okay. So we're going to be talking about RedwoodJS, and I think I was ever so peripherally familiar with RedwoodJS from before because the creator of it is Tom Preston-Werner, if I'm getting his name right, one of the co-founders of GitHub. I think I might have seen that he did an interview with Adam Wathan on Full Stack Radio. I don't think I listened to it, but I think I saw that one. Or maybe I listened to part of it.

So for an ignoramus like myself, how would you convey what RedwoodJS is?

00:03:03 - Anthony Campolo

RedwoodJS is a full stack JavaScript framework. It's funny that you say you first heard that he had done an interview on Full Stack Radio because I'm someone who listens to tons of podcasts, and I heard Tom explain Redwood on many, many podcasts, and it's kind of what got me interested in it in the first place.

To give a quick high-level overview, it's a way of combining React, GraphQL, and Prisma with a database in a way that gives you a full stack application that's using all this newer JavaScript single-page application technology and integrating it in a way that makes it nice to work with and coherent with a convention over configuration, opinionated kind of idea.

00:03:50 - Jason Swett

Okay, so I know what React is. I know what GraphQL is. I don't know what Prisma is. Can you explain that part?

00:03:58 - Anthony Campolo

Yeah, Prisma will be very simple for you to understand. It is basically ActiveRecord. Prisma is what is doing the ORM stuff. They went through a soul-searching process over the course of this year about whether to call themselves an ORM or not. They were trying to call themselves a query builder for the longest time, the idea being that a query builder is slightly lower level. It's really just generating a bunch of SQL for you. And it was really confusing for people because most people don't really know what a query builder is, but a decent number of people know what it is, and so they eventually decided to start calling themselves a next-generation ORM. That is the terminology they have landed on.

So basically it's just a way for you to define your schema. You have a Prisma schema, which defines what database you're using, which is going to be a relational database. It's either going to be Postgres, MySQL, or SQLite. And then you define a bunch of models. So you have a Post model. It'll have id, title, body, createdAt, and then that's pretty much it.

00:05:03 - Anthony Campolo

And then that is able to do all of the mapping from your objects to your relations. Prisma used to be a really heavy GraphQL tool when it was just Prisma 1. We're using Prisma 2 now, which actually has nothing to do with GraphQL. It's just a tool. Redwood is handling the actual GraphQL stuff.

There are other frameworks that also use Prisma but don't necessarily use it in a GraphQL kind of way. It's a really interesting tool. It's really flexible, and it's an interesting kind of new way of thinking about what an ORM tool can be.

00:05:39 - Jason Swett

So you have React at the most client-facing end and then at the bottom, maybe not the very bottom, but you have PostgreSQL. Maybe you have the operating system at the very bottom, but at the bottom of the application stack you have PostgreSQL.

What about in between React and Prisma, the ORM, or whatever you want to call it? Is it like a Node application? What's that part of it?

00:06:10 - Anthony Campolo

Yeah. So it's Babel at the very bottom of the stack because it is still just React and JavaScript, and it's kind of handling all the GraphQL mapping for you, so you don't really have to. It has Apollo baked into it.

Let me step back and first explain the project structure. Think of it as a monorepo with two folders. You have your web folder and your API folder. So if you've ever used Create React App, then that's like the web folder. That's just a React front end. Anything that you would be able to just create with Create React App or do with a Gatsby or Next kind of thing and throw that up on Netlify, that's your front end part.

Then your back end part splits into two. One is the Prisma stuff and one is the GraphQL stuff. That's basically how you want to think about your project. It's a full stack project, so you have a front end and a back end, but then your back end itself is decoupled into two pieces: your actual database piece and then your GraphQL piece.

00:07:14 - Jason Swett

Okay. And by the way, I want to interject something. Dear listener, you might be listening and you think, wait a second, this doesn't have anything to do with Rails at all. And yeah, that's totally true. I think it's healthy to have an awareness of what's going on in other development ecosystems and other communities and stuff like that.

There's this quote that I like to share, which I've probably shared on this podcast before, which is: there's an old fish and a young fish swimming in the water one day, and the old fish asks the young fish, how's the water today? And the young fish says, what's water? If you only ever spend your time in one ecosystem, then you're not going to know what's what. It's kind of like if you've lived your whole life in America and somebody's like, what's America like? And you're like, I don't know. It's just the default country. But that's not really it.

You have to go somewhere else and see what it's like somewhere else, and then come back and you're like, oh yeah, I went to this other place and it's different over there. They don't have traffic laws. They just drive all over the place. Crazy. It's different in different places, and so America is different in this way.

So all that is to say, this is why I'm having Anthony on the show to talk about this JavaScript thing that has nothing to do with Rails, to hopefully give us a little bit of perspective. Okay, Anthony, now that I've said that, where do you think we should take this next?

00:08:43 - Anthony Campolo

It actually has quite a lot to do with Rails. I would say that to say it has nothing to do with Rails is actually not correct at all because it was created by an old-school Rails developer. So I would say it actually has quite a lot to do with Rails.

00:08:53 - Jason Swett

Sure. Yeah, I would buy that. So having said those things, where should we take this next? What do you think would be the next concept to explain relating to Redwood?

00:09:05 - Anthony Campolo

Sure. First off, I would point out that I had also heard that "this is water" is from David Foster Wallace. He wrote a whole essay. I don't know if you know David Foster Wallace, author of Infinite Jest. That's something that I once referenced on my older podcast before I did my current podcast. I originally got into podcasting through music because I was a music major back in the day.

Anyway, the next thing you really want to know about Redwood is deployment. The idea is really important because Tom, the creator of Redwood, is an old-school Rails developer. Tom created GitHub with Rails, so he scaled one of the largest Rails applications in history and felt a lot of the pain of scaling Rails, and then went on to create this company called Chatterbug with Scott Chacon, another early GitHub creator. Chatterbug is a language learning platform, and they had a React front end speaking GraphQL to a Rails back end.

00:10:14 - Anthony Campolo

So that's why I say this actually has a lot to do with Rails.

00:10:18 - Jason Swett

So yeah. And I want to jump on something you said and make a comment. You mentioned the pain of scaling Rails. I don't know the history of GitHub's scaling story and stuff like that. I'm sure there was scaling pain, and I'm sure there was Ruby- and Rails-specific scaling pain.

What I don't want is any junior developer to hear that and draw the conclusion that Rails can't scale. Because it may be true that Rails has a hard time scaling to GitHub scale, but GitHub scale is crazy. And if you get there, good for you. You can deal with those problems at that point.

The fact that Rails might have trouble scaling to GitHub scale certainly doesn't mean that Rails is a slow choice for your new fresh app that you're creating today that's going to have six users for the next two years or whatever. So I just wanted to add my obligatory watch out for the "Rails doesn't scale" comment because however true it might be in certain situations, it might be less true in other situations.

00:11:33 - Anthony Campolo

Yeah, I think that's completely true, and it's a good call-out. It's one of those things where we try and compress so much information into our language when we talk about these things. This is why I love having these kinds of conversations with people in different communities because it's totally true.

It's not the idea that Rails can't scale; it's the idea that what if we could never have to even think about needing to scale Rails? What if we could hit GitHub level and just not have to worry about it? There is that small subset of applications that will scale to a level where you're like, oh no, there's a problem here. This model just doesn't work anymore. It's a very, very rare situation, but it could happen.

So the idea is: what if you're just set up for that no matter what, out of the box, just so you would never have to worry about it? You could get that success and not even have to trip about it.

00:12:19 - Jason Swett

Yeah, yeah. So that is one of the philosophies or components of Redwood.

00:12:26 - Anthony Campolo

Yes. I was just about to start talking about deployment, so this is a really good segue. This is the idea of being serverless by default. So when I say serverless to you, what does that word trigger in your mind?

00:12:39 - Jason Swett

Well, the facetious answer that I want to give is, I saw this T-shirt or sticker. It had a sad cloud, a crying cloud, and it said, "Serverless is just somebody else's computer." But also I just actually don't really know. I don't really understand what that term means. So I'm not even going to try to say my garbled, muddy conception in my head. How do you define that term?

00:13:10 - Anthony Campolo

Yeah, it's a lot less complicated than people make it. I would take it back a step and say, do you know what AWS Lambdas are?

00:13:18 - Jason Swett

Kind of. My understanding of Lambdas is like, you can spin up a server kind of on demand and have it run this specific service, but it's a limited thing as opposed to a web service in a traditional web server that you would have running all the time and serving a full application.

00:13:40 - Anthony Campolo

Yeah, you nailed it. It's the idea that it's this more event-based programming model where it just takes in events and triggers functions. But like you say, it's not a server that is always on, so you're only paying for the utilization of specific function invocations.

That is the idea, and that's why it can be extremely economically useful if you know how to architect your application in a way where you know exactly what functions are being triggered, how much they need to be triggered, and how much time they're going to take. You can optimize around all of those different metrics in a way that lets you not worry about scaling it, because you can just keep going up, but also not even have to pay for it until you start hitting millions of invocations.

00:14:23 - Jason Swett

Okay. And at what stage does that come into the picture, and how do you architect that? What I'm used to is you have one or more servers, and all those servers are running the same application. Scaling horizontally is when you just add more servers. And then of course there's scaling where your application gets slow because it's doing more stuff and you have to change the code in order to make it faster. That's a different kind of scaling.

But when would you bring serverless into the picture?

00:15:03 - Anthony Campolo

This is what makes Redwood interesting. It's the opposite. It starts serverless, and the question is when you bring servers into the mix because it's already serverless by default, the way a project comes out of the box. Then if you decide at some point you actually need a server, you can run it on a container. You can run it on something like Fargate, but it starts out just serverless.

What I mean by that is that your whole project, at the end of the day, has your React front end, and then you have your whole API folder back end, which is a whole bunch of Prisma stuff and a whole bunch of GraphQL stuff. All the Prisma stuff and all the GraphQL stuff gets shoved into one giant AWS Lambda.

I say these AWS Lambdas are like these things that just respond to functions and incoming events. The idea isn't to break up your application into a whole bunch of different Lambdas that do a whole bunch of different things. The idea is to shove your entire application into a single, giant function that is a Lambda, and that is your monolith.

00:15:59 - Jason Swett

I'm so glad that you said that, because until now I thought you were crazy. That's a much better way to do it, because I'm like, wait, is this guy advocating you have eight different Lambdas, like hosting? Do you do microservices from day one and all this stuff? No, you're saying just put your whole application on a Lambda and that's how you do it. That I can buy.

00:16:25 - Anthony Campolo

It's the exact opposite of a microservice. We are trying to get as far away from microservices as possible.

00:16:31 - Jason Swett

Yeah, okay. And what does that look like? So I assume you are, and I certainly am, an advocate of the idea of a walking skeleton. You deploy to production on day one so that you do all that hard, mysterious work right away. And then after that, everything is just incremental. Every deployment after that is a nonevent.

So what is involved in getting an actual Redwood application online? With Rails, you can host it any number of ways. You can use any cloud provider you want, and even inside of a cloud provider like AWS, you can deploy it to EC2, Elastic Beanstalk, which side note is a bad choice, or Fargate, or something else. There are all these different options, and there's not really one standard golden path. What about with Redwood? Is it similar where your options are kind of unlimited?

00:17:30 - Anthony Campolo

I wouldn't say they're unlimited, but they're definitely varied and expanding and getting more and more complicated. It was originally architected around Netlify for your front end and Heroku Postgres for your back end.

If you follow the canonical tutorial, which is how almost everyone who gets into Redwood gets into it, they go through a tutorial that basically walks them through it, very similar to what a lot of Rails developers did who went through a Rails tutorial that walks you through how to build a Rails project. It's the same idea. You build out a whole Redwood project, and at the end you deploy your React front end. So your web folder and your API folder and all that kind of stuff, like your whole project actually is deployed into the Netlify front end.

But then you also spin up this Heroku Postgres database on the side, grab an environment variable, and put it into your Netlify dashboard. By doing that, you connect your front end on Netlify to your back end, which is hosted on Heroku Postgres, and then that's your whole application.

00:18:31 - Jason Swett

To stop you and ask a question, and I can't believe how much I'm revealing my ignorance in this episode, but what is Netlify? I've heard of it. I have no idea what it is.

00:18:41 - Anthony Campolo

Do you know what GitHub Pages is?

00:18:43 - Jason Swett

Yeah.

00:18:44 - Anthony Campolo

Imagine you had GitHub Pages with a thousand more features.

00:18:49 - Jason Swett

That's okay.

00:18:51 - Anthony Campolo

Yeah. So it's a way to host your static front end, but also do a billion other things because now that we're building this whole quote-unquote Jamstack thing. Jamstack is just static sites to the nth degree with a million services around it and APIs and all this really complicated stuff to get to work. So we're trying to simplify all that.

00:19:08 - Jason Swett

Okay, okay. Got it. So you said Netlify on the front end and then Heroku Postgres on the back end.

00:19:17 - Anthony Campolo

But it doesn't have to be.

00:19:18 - Jason Swett

That doesn't necessarily have to be. Let me ask this too. Sorry I keep interrupting, but is there a Redwood tutorial? Is that part of the official Redwood docs? The same people who created the Redwood framework made the Redwood tutorial?

00:19:36 - Anthony Campolo

I'm actually really glad you asked that question, because Redwood has pioneered something that they are actually calling tutorial-driven development, which is the idea that the tutorial is what drives the entire project. The tutorial is what they put more work into than almost any other part of the project. They actually wrote the tutorial first and have built the framework around it.

So yes, the core team did do the tutorial. The tutorial is actually integrated in the project in a way that I don't think any other project has really ever done before.

00:20:04 - Jason Swett

That's amazing because funny enough, I think the Ruby on Rails documentation is pretty good, but there is no tutorial that's made by the same people who created Rails. The kind of de facto standard is Michael Hartl's Ruby on Rails tutorial, which is great.

00:20:20 - Anthony Campolo

That's what I was referring to. Yeah.

00:20:22 - Jason Swett

Yeah, yeah, and it's a great tutorial. I went through it and I recommend it to everybody, but it's kind of funny how there's not one that's put together by the Rails people. It's just very nice when the same people who create a framework create the tutorial for it, provided of course that they do a good job with it. But when all those things are true, it's just really nice.

00:20:48 - Anthony Campolo

Yeah, I think the Vue community has done a really good job with their documentation and tutorials. They're definitely something that I would point out that has really invested in that aspect.

What's cool about Redwood is because it's such a complicated framework with so many pieces, you have to introduce someone to it piece by piece. You start by just building out the React part. You don't worry about Prisma, you don't worry about GraphQL, you don't worry about any of that. First you're just building out your React front end, and then you start getting more into the Prisma stuff, and then you start getting more into the GraphQL stuff, and then eventually you deploy it, and then eventually you get [unclear]. It's a sequence that walks you through each piece. By the end you have the whole application in your head, but you didn't have to worry about all the bits at the end until you got to the end.

00:21:33 - Jason Swett

That makes a lot of sense. Yeah, because it's like, not until you teach somebody who's not all that familiar with web programming do you remember, like, oh wait, there's actually a bazillion things that you have to do all at the same time. And it's super hard to pick all this stuff up simultaneously. So that makes a lot of sense to introduce it bit by bit.

00:21:57 - Anthony Campolo

Yeah. I'm someone who was going through web bootcamp when I was first getting into Redwood. I was also kind of learning through other tutorials and trying to connect a React front end to an Express API with Redux and all this other nonsense, and it just didn't make any sense at all. Then I started going through the Redwood tutorial, and I was just like, this just makes sense. At every point in the journey, it made sense.

00:22:27 - Jason Swett

Yeah. That's great. Okay. So let's see, we talked about deployment. Let's, okay. The tutorial takes you through React, and then what does it introduce to you after that?

00:22:42 - Anthony Campolo

Then you start doing Prisma. Prisma is kind of integrated into the Redwood CLI. First off, there is a Redwood CLI that does a lot of the generating commands you would expect from something like Rails, like scaffold commands and all that kind of stuff that can give you a whole CRUD interface.

After you start doing your React front end, you write your Post model. You just write a single model for a blog post, and that's in your Prisma schema. Then you run some Prisma commands to create a migration. It creates a whole bunch of SQL to set up your tables for that post. Then you run another command to actually apply the migrations.

You're set up for SQLite as the database out of the box while you're in development. It's all just SQLite. Once you set up your database, you run the scaffold command, which allows you to create blog posts and have your whole blog interface.

00:23:36 - Jason Swett

Maybe we could zoom in for a second on Prisma. I've done Rails almost exclusively since like 2011, but there was a brief period in like 2014 or 2015 when I was doing some Node and Express stuff. I was somewhat aghast at the level of, how to put it, immaturity. That sounds kind of too derogatory, but I guess that's really what it is. I don't mean that in a negative way necessarily. It was just early days for all that stuff.

I was using Express at the time, and there was nothing that was even close to Rails Active Record. I couldn't even really find a Node ORM that was anywhere beyond a very early type thing. And it sounds like maybe that has changed since then. That was like five or six years ago now, at this point.

Is Prisma like a full-featured ORM? Can you talk about some of the stuff that it does? It sounds like it might even be, okay, so they're calling themselves a next-gen ORM or whatever it was. Is there anything actually to that, and if so, what is that next-gen part?

00:24:50 - Anthony Campolo

Yeah, I would say definitely. First off, within the last two or three years, there's been quite a lot of development in the Node ecosystem around ORMs. The other ones that are fairly well known now are Sequelize and TypeORM, and those are also fairly sophisticated.

What's really cool about Prisma is that when they say next generation, the reason is because it's eventually going to be able to work with both relational databases and document databases. That's one of the next-generation parts. We're not in that generation yet. We're kind of still getting there. But the thing that's really cool about it is that it is able to decouple your database in a way where you are just creating the models, and they're going to be able to figure out how to map between relational and NoSQL kinds of things.

So first off, let me break it apart. There's the Prisma Client and Prisma Migrate, and those are kind of the two different pieces that are important to know about, especially from a Rails background. Prisma Migrate is what's doing the actual important stuff that you would think of doing in terms of doing your table migrations, whereas the Prisma Client is what's mapping your model and your JavaScript and letting you do all that kind of database stuff by importing a Prisma Client.

00:26:10 - Anthony Campolo

So that's kind of where Prisma is at. It's a lot of things. It's really complicated. It's also a company with various other projects that can be integrated with it, like Nexus and stuff. So it's a lot of stuff.

00:26:21 - Jason Swett

Okay. Okay. I was going to, oh yeah. Another aspect of Node development back when I was doing it was it seemed that kind of the default back end choice, the default data store choice, was something like Mongo, a document database. And again, not being in the JavaScript world, the Node world and stuff like that for a long time, is that still a popular default choice for a data store, or are people more reaching for something like PostgreSQL these days?

00:26:57 - Anthony Campolo

It's an interesting question because I would say it really depends where you're coming from and what you learned in the first place, and what you were trained in. Some people are given the MERN stack or the MEAN stack, which is just Mongo, Express, Node, and then some kind of front end. It could be Angular, React, or Vue. They just learn how to build a full stack app with Mongo and it works. It's good for them and they don't have to think about a lot of stuff you have to think about with SQL, so they just never bother with it because they don't really realize exactly what they're not getting by not having a relational database. If you've never used it, it's hard to actually understand the difference between the two of them.

So Redwood is relational entirely by default right now. It essentially only really works in a relational way because of Prisma. Prisma only works with relational databases. This is why I say Prisma is eventually going to get to the point where it can be used with Mongo. Lots of people want it to be used with Mongo, and lots of people want to use Redwood with Mongo. Everyone's asking for Mongo support all the time. But right now we're like, no, this is the way to go. We'll get to Mongo eventually, but this is the way to go for now. So yeah, it's a really interesting discussion.

00:28:12 - Jason Swett

Yeah, yeah. You know, I go through periods, I think, as you get older, you start to have these experiences. I go through periods of anger and frustration when I see a wave of junior developers come in and they're given certain advice that's not necessarily very good advice.

My big thing I've been ranting on a bunch lately is service objects in Rails, because a lot of junior developers have developed this idea that the way to organize your code in Rails, when it's not in a controller or model, is to use service objects. People have heard me talk about this ad nauseam on this podcast, so that's my unhealthy fixation right now.

My unhealthy fixation five years ago was the whole Mongo thing. And it's one thing to say, okay, I understand PostgreSQL very well. I understand Mongo very well. I'm weighing all the pros and cons of these for my use case, and I'm going to choose Mongo. Like, that's great. But what was happening back at this time was people were just saying, oh, relational databases are old and yucky, and I'm not going to do that anymore because that's the old way. I'm going to do it this new, better way using a document database. But it wasn't really an informed decision. So I'm glad to hear that maybe there has been some more maturity around that decision-making as the years have gone by.

00:29:44 - Anthony Campolo

Yeah, totally. And that's why part of Redwood, even though it's integrating all these kind of new cutting-edge pieces of tech, it's also doing it with really stable, battle-tested tech as well, like Postgres databases. It's saying, we don't need to sacrifice all this other stuff that we've already built up just to jump into this whole React world. We can figure out ways to integrate these two universes.

00:30:11 - Jason Swett

So where would you find the bulk of the code in a Redwood project, if that makes any sense? Would the bulk of it be in the React portion of it, or would it kind of be equally distributed on the front end or back end, or is it maybe even a question that doesn't really make that much sense?

00:30:26 - Anthony Campolo

It's definitely a question that makes sense. The answer is it depends on what you're building with it and what you're trying to get out of it, and whether you want to use other frameworks as well.

Some people really like the Redwood API and the whole GraphQL part of it, but they think the website is kind of lacking in comparison to something like Next.js. For people who aren't familiar with Next.js, it's a React framework that does tons and tons of amazing stuff for you in terms of server-side rendering and static generation, just like dealing with all that kind of stuff that goes along with pages in a modern web application. It does a ton of stuff right now that Redwood can't necessarily do and that it will be able to do at some point in the future.

But some people who are building real-world applications today with Redwood choose to write Redwood entirely with the API and then not use the web folder at all, and then use Next as the front end part.

00:31:19 - Anthony Campolo

But other people will have a very minimal API and will build a very complicated, built-out web front end. It really just depends what you want to do with it and what you want to build with it.

00:31:28 - Jason Swett

Okay, this has been great because it's helped me talk about these things and be exposed to these technologies that I never otherwise would be exposed to. I love it when somebody can say, like, oh, and we use blah, blah, blah tool, and I'm like, what's that? Netlify. What's that? So that's great. It's broadening and very helpful, and I hope it's been broadening for the listeners too.

Where can people go to find wherever you would like to send them? To find more about you, to find more about Redwood, any of that stuff?

00:32:06 - Anthony Campolo

Yeah. RedwoodJS, you can just go to redwoodjs.com and that'll get you to either our docs or our community forum or our Discord. We're really very community-focused in the sense of wanting to get people involved. We want to get contributors. We want to make it open to anyone who wants to contribute, wants to get involved, because we really enjoy building Redwood with everyone.

I'm someone who just saw it, thought it was cool, started doing stuff with it, and I've gotten more and more involved in it and deeper and deeper into it to the point of getting onto the core team. It's been awesome for me in terms of getting me opportunities and getting a foot in the door with certain job offers and things like that. So yeah, it's been really incredible.

And if you want to find me, I am @awebdev on Twitter or GitHub, or dev.to. I have the same handle on all of them.

00:33:00 - Jason Swett

All right. And we'll put all that stuff in the show notes, of course. Anthony, thanks so much for coming on the show.

00:33:06 - Anthony Campolo

Yeah, thanks for having me. It was a blast.