RedwoodJS the JS App Framework - JavaScript Jam

Episode Description

Anthony Campolo shares his journey from music teacher to RedwoodJS core team member and demos building a full-stack app with the Rails-inspired framework.

Episode Summary

In this episode of JavaScript Jam, Anthony Campolo, developer advocate at Stepzen and core team member of RedwoodJS, walks through his unconventional path from music education to becoming a prominent voice in the JavaScript ecosystem. He explains how creating content around an up-and-coming open source project helped him stand out after boot camp, offering practical advice for career changers. The conversation then shifts to RedwoodJS itself, exploring how Ruby on Rails heavily inspired the framework's conventions and opinionated structure, with Tom Preston-Werner's experience scaling GitHub informing much of the design philosophy. Anthony gives a live demo covering project setup, database provisioning with Railway, Prisma migrations, scaffold-generated admin UIs, and Redwood's unique "cell" pattern for declarative data fetching with GraphQL. The hosts and Anthony discuss how Redwood compares to competitors like Blitz and Bison, particularly around the philosophical question of whether developers want a GraphQL API layer or prefer direct database calls. They also address real-world concerns like serverless-to-Postgres connection scaling, authentication options, and the framework's path toward a 1.0 release expected in early 2022, with several companies already running Redwood in production.

Chapters

00:00:00 - Introductions and Anthony's Career Journey

The episode opens with a teaser from Anthony about the importance of creating and sharing projects publicly, followed by the hosts introducing him as a developer advocate at Stepzen and RedwoodJS core team member. Anthony shares his background as a former music teacher who transitioned into coding about three years prior, describing how he initially struggled with Python and data science before finding his footing with web development through Lambda School.

Anthony explains how he discovered RedwoodJS while going through his boot camp curriculum and began writing blog posts and tutorials about the framework, which eventually led to an invitation to join the core team and ultimately a job at Stepzen. His story illustrates how latching onto an emerging open source project and producing content around it can accelerate a career transition in tech.

00:04:53 - Advice for Career Changers and Boot Camp Graduates

Anthony addresses the common question from boot camp graduates about how to break into the industry, emphasizing that the single most important thing is to create and share work publicly. He recommends building projects, blogging, making videos, and attending meetups, noting that attaching yourself to an up-and-coming open source project is a particularly effective strategy for gaining visibility when there isn't much existing content around it.

He points out that thousands of people graduate from boot camps with similar credentials, making it difficult to differentiate yourself with just a certificate. The key is building a portfolio of work that you can point to and attach your name to, which compounds over time and gives potential employers concrete evidence of your skills and initiative beyond what a classroom experience provides.

00:06:11 - What Is RedwoodJS and Its Rails Inspiration

The conversation turns to RedwoodJS itself, with Anthony explaining that it is a full-stack JavaScript framework heavily inspired by Ruby on Rails. He highlights that Tom Preston-Werner, the creator of GitHub — one of the largest Rails applications ever built — leads the project, and that team members like Rob Cameron consistently look to Rails conventions when solving problems. Mark adds context about what made Rails great, including its opinionated nature, convention-over-configuration philosophy, and the gem ecosystem.

Anthony notes that Prisma, specifically Prisma 2, was the key technology that enabled building a Rails-like framework in JavaScript, serving a role comparable to ActiveRecord as the ORM layer. The discussion touches on how JavaScript and React have historically been very unopinionated, and Redwood's goal is to bring Rails-style conventions to the React ecosystem while leveraging modern JavaScript tooling.

00:10:39 - Team History, Tech Choices, and the Next.js Decision

Anthony recounts the origins of Redwood, explaining how Tom Preston-Werner and Peter Pistorius started the project in 2018 while working together on Chatterbug, a language learning platform that used a Rails backend with GraphQL connecting to a React frontend. The team grew from four members at public launch in March 2020 to fourteen at the time of recording, with plans to reach around twenty.

A key discussion point is why Redwood chose not to build on Next.js, with Anthony explaining that the team wanted full control over the framework, especially the routing layer. He references the Blitz framework's eventual decision to fork away from Next.js as validation of Redwood's approach, and mentions his podcast episode with Blitz creator Brandon covering that decision in detail.

00:15:02 - Core Libraries, GraphQL Stack, and Getting Started

Anthony outlines the batteries-included technology stack within Redwood, including Apollo Client on the frontend, the newer GraphQL Helix server replacing Apollo Server on the backend, and built-in tooling like Storybook, Jest, and Mock Service Worker for testing and mocking. He describes a significant but under-discussed shift in the GraphQL ecosystem away from Apollo Server toward Helix and Envelope.

For developers wondering what they actually need to know before trying Redwood, Anthony simplifies it considerably: know React, and you can learn everything else along the way. Prisma commands are bundled into Redwood's CLI, and the GraphQL layer is largely abstracted away, so the primary code developers write is React code with some schema definitions.

00:17:42 - Live Demo: Project Setup, Pages, and Routing

Anthony begins a live demo by creating a new Redwood project and provisioning a Postgres database using Railway. He walks through the project's directory structure, highlighting the separation between the website folder for the frontend and the API folder for the backend server code. Using the Redwood CLI's generate command, he creates pages that automatically get wired into the routes file.

The discussion covers how Redwood handles routing differently from Next.js — using a declared routes file rather than file-based routing — while still offering convenience through automatic route registration when generating pages. Anthony also explains that pages are client-side rendered by default, with an optional pre-render prop for static generation, and that full server-side rendering is planned for after the v1 release.

00:26:43 - Database Setup with Prisma and Scaffold Command

The demo moves into the backend, where Anthony sets up a Prisma schema with a post model containing fields for id, title, body, and creation date, connected to the Railway Postgres database via an environment variable. He runs a migration and then demonstrates the scaffold command, which generates a complete CRUD admin interface including routes, components, and forms based on the model definition.

The scaffolded admin UI allows creating, editing, and deleting posts directly in the database, with the data visible in Railway's dashboard. The hosts highlight how much the scaffold automates, including pluralizing model names for routes and generating all necessary component files, drawing a direct parallel to the Rails scaffold experience that inspired it.

00:32:39 - Cells: Redwood's Data Fetching Pattern

Anthony explains Redwood's cell concept, the framework's convention for declarative data fetching. A cell defines a GraphQL query along with exported components for different states: loading, empty, failure, and success. He demonstrates importing a cell into a page and progressively enhancing it — first showing just post IDs, then adding title, body, and timestamp fields, and finally styling the success component to render a basic blog layout.

The hosts emphasize how this pattern removes boilerplate by letting developers simply describe what should happen in each lifecycle state while the framework handles the wiring. Mark asks about query customization like filtering and pagination, and Anthony points to Redwood's cookbook documentation while noting that anything possible in GraphQL works within Redwood's cell pattern.

00:37:28 - Deployment and Serverless Database Challenges

Anthony demonstrates deploying the Redwood app to Netlify using a single CLI command that generates the necessary configuration, with the API folder compiled into a single Lambda function. He notes that Render stands out as a deploy target because it can host the frontend, server code, and a Postgres database all in one place, unlike most other platforms that require a separate database service.

The conversation turns to a significant challenge with serverless architectures: Lambda functions creating too many simultaneous connections to Postgres databases. Anthony acknowledges this is a real issue, discussing solutions like PG Bouncer and RDS Proxy while noting that Prisma's compatibility with these tools is still evolving. He pragmatically suggests that if connection pooling becomes too complex, developers can simply run Redwood on a traditional server instead.

00:42:58 - Road to 1.0, Production Apps, and Competitor Comparison

Anthony shares that Redwood is very close to a release candidate, with a production 1.0 expected in early 2022. He highlights several companies already using Redwood in production, including Everfund, a donations platform, and User Vitals, a user feedback tool. The discussion then shifts to comparing Redwood with competitors Blitz and Bison, with Anthony framing the choice as a philosophical question about APIs — Redwood provides a GraphQL API layer that enables easy multi-client support, while Blitz skips the API entirely for faster prototyping.

All three frameworks share React and Prisma as foundational technologies, with GraphQL being the key differentiator. Anthony also addresses Redwood's "eject" story, explaining that because the frontend and backend are already decoupled, developers can drop either side independently if needed, giving the framework a natural flexibility advantage.

00:53:11 - Roadmap, Closing Thoughts, and Where to Find Redwood

Anthony discusses the Redwood roadmap, expressing personal excitement about the Docker deployment story he's been helping develop, as well as the completed migration from Apollo Server to GraphQL Helix. He notes that at this stage, the focus is less on adding new features and more on polishing, fixing bugs, ensuring Windows compatibility, and completing documentation — the unglamorous work needed to ship a reliable 1.0.

The episode wraps with Anthony directing listeners to redwoodjs.com as the starting point, along with the project's Discord and Discourse forum for community support. He shares his personal handles under AJC Webdev and promotes his podcast FSJAM at fsjam.org, thanking the hosts for the opportunity to give a Redwood demo after a long break from his earlier meetup talk circuit.

Transcript

00:00:00 - Anthony Campolo

The one main blanket advice that you really want to follow is create something like put stuff out into the world. You want to be building projects, you want to be blogging about those projects, you want to be creating videos about that project, you want to be going out to meetups to talk about those projects. It really doesn't even matter what it is. And so the hack is, how do you make that content compelling?

00:00:26 - Ishan Anand

Hello everyone, I am Ishan Anand, head of product at Layer Zero.

00:00:31 - Mark Mercato

I'm Mark Mercato, VP of engineering at

00:00:33 - Ishan Anand

Layer Zero, and welcome to JavaScript Jam. On today's episode we have Anthony, who's a developer advocate at StepZen and a core team member and developer advocate at RedwoodJS. RedwoodJS is one of the leading contender frameworks in JavaScript to take the crown of Ruby on Rails. So really excited to have him here and hear more about RedwoodJS. Welcome, Anthony.

00:00:59 - Anthony Campolo

Hey, thanks so much for having me. Really happy to be here. I just had [unclear] very recently on my own podcast, which is yet to air, but it'll be fun to continue to talk about these jamstack ideas. I know you guys are all very interested already, and Redwood I think really fits into that whole story.

00:01:17 - Ishan Anand

Yeah, it totally does. Before we jump into Redwood, could you just give us some idea about your background and how you got involved with Redwood?

00:01:25 - Anthony Campolo

Yeah, I love telling my story because I think it's good for people who are maybe in a similar boat in terms of being a career changer or someone who is not from a quote-unquote traditional background. Although I'm finding that the more traditional background these days seems to be boot camp people who used to be humanities majors. So I used to be a music teacher, so I have a music education degree and I spent a little time teaching at public schools and then I ran a performing arts summer camp for about four years. So I got a taste of admin work and event planning and how to run a small business. And throughout all that, I had drifted away from what I really enjoyed, which was like creating. And so I found coding was an interesting niche to get into because it kind of scratched that itch of wanting to always have new things to learn and be able to create interesting stuff that you can then share with others. But it was also a hard skill that companies were willing to pay a lot of money for. So I started learning to code probably about three years ago now and hacked at it on my own, trying to learn Python and data science stuff, which was a huge failure.

00:02:39 - Anthony Campolo

I barely made any headway at all into that. And at a certain point I re-evaluated and went deeper into web and started learning HTML, CSS, JavaScript and then joined Lambda School, which is a very well-known boot camp that just got a huge, huge Series C funding round, I think, not too long ago. And as I was going through that boot camp, I was learning full-stack web development, I was learning React and Express and Postgres, and at the same time I was looking at the open source world and what else was available beyond the things I was learning in my boot camp. And I saw RedwoodJS, and RedwoodJS is a full-stack JavaScript framework. It uses GraphQL, but it's really React and Node basically, with a Postgres database. So as I was going through my boot camp, I was learning about Redwood and I was listening to podcasts about it and I just started writing about it. I started blogging and I went through the entire tutorial front to back and got to a little demo here that will show a decent chunk of what that is. And then eventually I started getting more involved with the team and going to meetings.

00:03:48 - Anthony Campolo

And then at a certain point they invited me to be an actual core team member. And then not too long after that I actually got a real job at StepZen thanks to the exposure I had gotten through my Redwood work.

00:04:00 - Ishan Anand

I think your story is so compelling because you know, you went in three years from boot camp to core team member on a hot JavaScript framework, you know, a job at an interesting company. Like it's, it's really inspiring. And we should mention, you host a podcast — we should mention that one, FSJam, which I totally recommend everyone checks out. You cover the whole space. You're not covering just Redwood, you're covering all the other Full Stack jamstack frameworks. But what advice would you give to other folks who are career changers? And we host a room every week in clubhouse called JavaScript Thursdays. And we get a lot of people who are in that situation and they're asking, I just got off a boot camp, what should I do? It's great to have somebody like you to point to, but what would you say that really would make the difference in those early days?

00:04:53 - Anthony Campolo

Yeah, it's very much a hard thing to just give blanket advice — it's really going to vary from person to person. But the one main blanket advice that you really want to follow is create something, like put stuff out into the world. You want to be building projects, you want to be blogging about those projects, you want to be creating videos about that project. You want to be going out to meetups to talk about those projects. It really doesn't even matter what it is. And so the hack is, how do you make that content compelling? And so for me, that was latching on to a popular open source project that was up and coming. It doesn't necessarily need to be that, but it's a good kind of hack to get yourself a lot of attention if you glom onto something else that already has a lot of attention but there's not a lot of people creating content around. But the main advice is just create stuff that you can put out and attach your name to, because then that will start to accrue and you'll be able to actually point to things saying, here, this is stuff I've made, this is stuff I've done.

00:05:55 - Anthony Campolo

Otherwise everyone's coming out of a boot camp with a boot camp degree, a certification — whatever that means. There's hundreds, thousands, tens of thousands of people coming out of these boot camps and it's really hard to stand out if you just have the boot camp certificate and that's all you have.

00:06:11 - Mark Mercato

Makes sense. So let's switch to RedwoodJS. I'm an avid lover of Ruby on Rails, so I'm wondering: A, just give us a description of what RedwoodJS is, and B, how much did Rails influence RedwoodJS? Was it the benchmark that the team went after, or were there other frameworks that were more inspirational?

00:06:31 - Anthony Campolo

Sure. Redwood is a full-stack JavaScript framework and you can say quite definitively that, yes, Ruby on Rails is the main overriding inspiration for the project. You can see this in a couple ways. One is that the framework is being headed by Tom Preston-Werner. Tom Preston-Werner is well known as the creator of GitHub, which is quite possibly the largest Rails app of all time — up there with things like Shopify and other really massive Rails applications. So he was scaling Rails back in the mid to late 2000s. He has a ton of Rails experience. And then you have people like Rob Cameron on the team who will essentially say any and all problem in web development was already solved by Rails. Like, no matter what issue we're coming up against, he's like, here's how the Rails people solved it — just figure out how to do that in the most similar way you can. And so that philosophy is baked into the team. But the real key piece is the ORM layer, I think, because when we talk about what a full-stack framework is.

00:07:30 - Anthony Campolo

That means it's a front end and a back end. And the question of how you mediate between those two is a huge question. So with Rails, you have ActiveRecord — I've never used Rails, I don't really know a ton about the real nitty-gritty mechanics of it, but I know that ActiveRecord is a key piece of it. And once Tom and the team saw Prisma, Prisma 2 specifically, they're like, okay, that's something close enough to ActiveRecord that we can build a framework around, because that's gonna let us work with our database, do migrations, set up our tables, write to those tables — and that'll be some of the stuff we'll be showing in the demo today.

00:08:07 - Ishan Anand

Should we actually back up a second? For people who haven't touched Ruby on Rails or don't really know much about it — Mark, I know you've done a ton with it, and Anthony, I assume from the inspiration it gives to Redwood — do you guys just want to educate folks on what made Ruby on Rails so great? For somebody — imagine they're an alien from Mars and have never touched it —

00:08:28 - Mark Mercato

you can take that, Anthony.

00:08:29 - Anthony Campolo

Yeah, I'd be curious to kind of hear how Mark would describe it. But the main thing is MVC — Model, View, Controller — I think is a good way to think about it. You have a model which is like your database model, you have a view which is your front end — what the user is actually seeing — and then you have a controller that mediates the logic between the two.

00:08:49 - Mark Mercato

Yeah, and I'd add to that — it's a highly opinionated framework that's pretty highly focused on web applications that manage a database. And it took a very interesting approach in that through gems, these reusable bits of functionality, you essentially piece together a website through all the common things that most websites do or most web applications do. So it's meant to make the developers really high velocity, and it's meant to solve all the common practical problems around building a web app. When you're a really small team and you have no resources, and I would still say today, if you fit that bill, if you're one guy or five people working on a thing in your garage, Rails is the best way to get bootstrapped. It gives you the highest velocity and allows you to ship something really quickly. And it, it scales and holds up really well. Like you've seen from GitHub and Twitter, these big sites use Rails pretty far into their success. So I think the things that it really brought to the table was like being highly opinionated, convention over configuration, and these coarse grain chunks of functionality being added to apps through.

00:10:00 - Mark Mercato

through gems.

00:10:02 - Anthony Campolo

Yeah, and that definitely tracks with Redwood. It's the opinionation and the convention-over-configuration that's an interesting point to make, because JavaScript historically has fought against conventional configuration, has been very unopinionated, and the React world has modeled the JavaScript world in that sense of being very unopinionated and having no convention. So Redwood is saying, okay, we've had React for a while, we know we like it, we know we want to build around it, but it's time for us to create some conventions to actually make it more manageable so we can have a nice developer workflow that's Rails-y but uses this newer technology.

00:10:39 - Mark Mercato

Got it. How big is the team behind Redwood?

00:10:43 - Anthony Campolo

Yeah, right now we are at like 14 core members. We're just about to add a handful more, so it's been growing. To get a little bit into the history of the project: it first started just with Tom and Peter — Tom Preston-Werner, whoever knows him from GitHub, and Peter Pistorius, who's not as well known, but he was a developer working on Chatterbug with Tom at the time, which was a language learning platform. They were building an application that basically had a Rails back end speaking GraphQL to a React front end. They found it was just a hard application to manage — figuring out how to smash those two worlds together with this GraphQL intermediary got them most of what they wanted, but it just took so much work to actually get it functioning. So they're thinking, how can we create a framework that's going to use all this tech and do it in a way that's more native to the JavaScript world? And so this was in 2018 — this is a while ago — and they were batting ideas around and then started creating the actual repo in June of 2019.

00:11:52 - Anthony Campolo

But most people didn't hear about it until March 2020, which is when it kind of was announced to the world. At that point it was four people — Tom and Peter, and then they had brought on their friends David Price and Rob Cameron. I've had all of these people on FSJam, if you're curious about learning more about their whole stories and histories. They've been building up the team ever since then, adding people incrementally [unclear]. So it went from four back then, over the course of a year and a half, to 14 now. And then we're about to add like three or four more, so we're gonna be close to around 20 pretty soon.

00:12:33 - Mark Mercato

Got it. And how did they decide what pieces of the JavaScript ecosystem to build on? Like specifically, Next.js — at least now, maybe not in 2018 — is far and away the most popular framework, I think, in the React world. And notably RedwoodJS is not built on top of Next.js. So was that ever considered, and what was the process behind deciding what to put in the box versus what to leave out?

00:12:58 - Anthony Campolo

Yeah, and so this is stuff that happened long before I was on the team. But having listened to every podcast Tom has ever done, I've got a pretty good idea of the outline here. It was a fairly fluid process in the sense that they were building this and they were looking at what's available, pulling in different pieces and taking pieces out, kind of just trying to reach a local maximum of what they thought would be the best combination of tools — like Prisma especially. There used to be Prisma Nexus in the framework, which is this whole other separate thing. So the pieces of tech mostly just came from having researched and known the area as working developers for many years. Peter especially had a really big influence here because he was a React Native developer for a long time. And as they were doing this, they really wanted to have control over the framework, even though it was going to be made up of other open source pieces. So I think Next just took up too much real estate and was going to be too big of a driver for them to really buy into.

00:14:08 - Anthony Campolo

And this is really interesting because Blitz is the contrast here in that Blitz does build on Next, but they ended up, after a long time, parting ways with Next because they didn't have enough control over it. So that to me was kind of like almost ratifying the decision Redwood had made to have more control over that layer. And it's all about the routing — they wanted to have control over their own router, and you couldn't do that if you used Next.

00:14:32 - Ishan Anand

Yeah, and I'll just give a shout out — you have an episode of FSJam, I think, where it's you talking to Brandon, the creator of Blitz, specifically about the decision to fork. I think you spent a whole episode on that.

00:14:44 - Anthony Campolo

Yeah, I thought it was really fascinating. Yeah, yeah. And I was surprised that it didn't seem to get as much attention in the kind of like, main space of the tech conversation, because it's a really compelling story because it's a very large framework using another very large framework and designing it, fork them. So that doesn't happen very often.

00:15:02 - Ishan Anand

Yeah, it'll be interesting to see what happens there. But maybe we should jump into the demo and walk people through what makes Redwood so great. But before we do that, just if you were to outline what the core pieces are. We've talked about Prisma. What are the other core libraries, like, say the top three or four that are already bundled for you? Batteries included in Redwood.

00:15:25 - Anthony Campolo

Yeah. So the GraphQL stuff is what you kind of want to wrap your head around. I work for a GraphQL company — I'm very deep in the whole GraphQL space. And most people, when they hear GraphQL, they think Apollo. So you have Apollo Client and Apollo Server — those are usually the front end and back end pieces that make up a full-stack GraphQL application. Now this has gotten much more complicated from when Redwood was created. Apollo Client is the default, but if you want you can switch it out for React Query. Apollo Server is no longer the default at all — we've actually chucked it for a brand-new server called GraphQL Helix. This isn't super important if you don't want to dig into the lower levels, because part of the benefit of Redwood is that you don't have to think about all these underlying libraries. But I really recommend people who are interested in GraphQL to look into Helix and Envelope, especially because this is, I think, a sea change in the GraphQL world that's kind of happening under the surface and not a lot of people are aware of.

00:16:25 - Anthony Campolo

But Apollo Server is old news — it's no longer cool, if you know. Those are the main things happening: you have Apollo on the front end, you have this new GraphQL server Helix on the back end. And then you have tooling — you have Storybook and Jest, so UI testing and mocking are all built in already. You can just run commands to basically get Storybook up or get Jest tests running. They also have Mock Service Worker doing your mocking, so it has a lot of pieces in there that Rails developers would expect. If you want a whole bundled framework, that also means you can't just build the thing — you have to be able to test and verify that it works as well. So that's also all built in.

00:17:09 - Ishan Anand

So I guess let's keep it from the perspective of somebody just wanting to try it out. What are the technologies they need to know? I'm hearing GraphQL, React Query, Jest, React. Don't even need to know Prisma really.

00:17:21 - Anthony Campolo

Well, I would say not even React Query yet. Prisma? The Prisma commands are bundled into the Redwood CLI, so the actual code you are going to write is going to be React code. So I would say you need to know React. If you don't know React, you should learn some React before you use Redwood. Everything else you can pick up on the way.

00:17:40 - Ishan Anand

Great. Well, let's jump into the demo.

00:17:42 - Anthony Campolo

Awesome. So I'll go ahead and share my screen and minimize that. I have just a little gist here that I'm going to use to kind of follow along with. We're going to do a couple things. We're going to start by creating a project, we're going to provision a database — I'm going to use Railway; you could use Supabase, you could use Heroku, you could use Fly, there's a million ways to get Postgres databases spun up now — but the main thing is you want to just have a database you can use. And then we're going to use Prisma to actually set up the database, run migrations, and then I'll talk about what a cell is once we get to it. That's how we do the data fetching. And then this may be a bit of a faux pas, but I'll be deploying to one of your competitors. Unfortunately we do not yet have a Layer Zero integration, but let's work on that.

00:18:34 - Ishan Anand

But yeah, no worries.

00:18:37 - Anthony Campolo

Yeah, so this first command is going to take a bit of a second. So while that's going, I'm going to kind of show just what Railway is — this is going to be how we spin up our database. It's awesome, it's just a really fast, easy way to get a database up and going. So while that's installing, I'm going to jump a step ahead here. This is going to initialize a project and all we want to do is give it a name and then give it an add-on. And so the add-on is going to be a Postgres database. So you can do railway add after railway init and it shows you some of the stuff that's available. I think of it like a backend Netlify or Vercel — it's just like I want to get something spun up really quickly and have a nice interface to it. And you can do all this with just the Postgres database, which is really nice. So if you then check your Railway over here, we actually have this Postgres database and it's got connection strings and everything we can use to access it.

00:19:58 - Anthony Campolo

Now that we got our project set up, let's just kind of see what we got here. It's going to first give you a little Hello World splash page on localhost 8910. And it's also going to have you set up to do the database migrations as well. So let me open up a code editor. The main thing you want to know about a Redwood project is that you're going to have a website folder for your front end and then an API side for your back end. Part of the reason is because you actually have server-running code, whether that's a serverless function or a Docker container. So you are going to have an actual server and an actual front end, and those two are kind of separated in the project with your API

00:21:07 - Ishan Anand

And — maybe just pause there for the audience to elaborate on what you're saying here. What you're saying is basically it's Jamstack or headless where the front end is entirely statically generated. Is that correct? And then everything else that you're using the server endpoints for — the API data — that's what the server's for. Is that basically correct?

00:21:30 - Anthony Campolo

Yep. So if you take a look at the website, it will look fairly familiar. If you've ever worked with Create React App or something like that — you have an src folder that's got all your React code, your pages and layouts and components — those should all be fairly standard for working with these kinds of applications. And then you have your public folder which has icons and things like that. But the easiest thing to show first is just what a page is with Redwood, because similar to Next, you already have page stuff built in. And we also have a really nice CLI that lets us generate most of the things we're going to want to generate with the Redwood project. All the commands start with yarn redwood and then generate — you can write the word generate or just the letter G — and then you tell it the thing you're going to generate. You can generate almost all the different components of a Redwood app. Right now we're just generating a page and we want that page to be called Homepage.

00:22:35 - Anthony Campolo

And then the path we want to set is going to be just the forward slash — just our home page. So if you had ajcwebdev.com forward slash, that would be your home page here. And then this was placed in our Pages folder, in our Homepage folder and our homepage right here. And we can just kind of edit this to say "Hello, JavaScript Jam," and then we save and we automatically see the changes here. So, questions so far?

00:23:12 - Ishan Anand

So maybe we should tell the audience a little bit of a map of the directory structure. I mean, it's very similar to a lot of other projects. But when you did the generate, for example, you have two other files. It looks like Storybook and Jest. Is that correct for testing?

00:23:27 - Anthony Campolo

Yeah, exactly. Yeah. So Storybook. And then you have just a basic test here that is rendering the homepage. So just making sure that your whole component is not broken. Obviously you're going to want to write actual tests beyond that. But this is kind of like a good starting example. And then it also comes with a meta tag too, which is pretty nice.

00:23:46 - Ishan Anand

And how would you handle, for example, dynamic routes? So you know, product slash id?

00:23:53 - Anthony Campolo

Yep. So that is where the routes file comes into play. So this is where the actual router is set up. It's like a react router or something like that, where you have router that is wrapping your actual route components. And then so here is where you would actually do all of that kind of stuff. So if you go, we have a tutorial that is really, really built out and is how most people learn how to use Redwood. So there's a whole section on routing params and how to set that up. And this will be a little outside the scope of what I'll be showing, but we got a whole document here explaining how to do that.

00:24:30 - Ishan Anand

Interesting. Okay, so you don't follow, for example, the Next.js convention where it's a special file name and the router just kind of automatically picks it up. It's not necessarily always file-based routing.

00:24:43 - Anthony Campolo

Right. It's declared here in this routing file. And so it's trying to get the best of both worlds in that it gives you the flexibility of something like a react router, but it sets it up for you.

00:24:55 - Ishan Anand

Yeah. So when you do the generate, it will automatically add it to the routes for you. So it almost.

00:25:00 - Anthony Campolo

So check this out. So if we were to create an about page instead of a home page, then it's going to create a page like that and then automatically maps the page to the route. Okay.

00:25:12 - Ishan Anand

Ah, great.

00:25:13 - Anthony Campolo

And then if we go over here to about and bam, there's your about page.

00:25:17 - Ishan Anand

Got it. Okay. And then that gives people the flexibility, but also the ease of use. It sounds like that makes sense.

00:25:25 - Anthony Campolo

That's the idea.

00:25:26 - Ishan Anand

Okay. And then the pages are server side rendered, client side rendered. How is.

00:25:33 - Anthony Campolo

They are client-side rendered by default, but there is a pre-rendering option that will let you actually statically generate pages if you want. And essentially all you do is add this pre-render prop to your route. So that's for deciding between which ones you want to be static versus just client-side rendered. We don't yet have an actual SSR solution, but it's something we get asked about constantly. So it will likely be the first thing we start working on after V1 comes out.

00:26:08 - Ishan Anand

Got it. So that pre-rendering is the Jamstack pre-rendering where it'll pre-render essentially the front of it. But if there's a product page for each product, you're basically just pre-rendering the shell, so to speak, rather than each one.

00:26:21 - Anthony Campolo

Yeah, exactly. And the reason we haven't really put a ton of work into that is because it's like, there already is a server. If you just want to run server code and do whatever you want, you can do that — it's there. So that's why we don't really have an SSR convention yet. But there's nothing stopping you from just doing it yourself, because there is a server.

00:26:38 - Ishan Anand

Got it. Mark, did you have anything else before we let you keep going on your demo?

00:26:43 - Mark Mercato

Well, maybe it's a good segue to the next thing, which is how do we start incorporating data from the database?

00:26:47 - Anthony Campolo

There we go. So that is going to be the next thing. This is where we're going to move into our API folder. And here we have Prisma. Prisma is kind of almost like code setup in terms of how you use it, because they have their own schema.prisma file. What's really cool about this is you get to both specify your database and your model. So we're telling it here that we want Postgres — it was SQLite originally — so you can switch between one or the other, although it's not entirely seamless. I'd recommend just picking a database at the beginning and using that one; as long as you kind of stick with the same one, it's usually fine. And then we set the model here. You create a database model: id, title, body, and created at. And the way you actually connect it is with a database URL here. This is just a command that basically takes your Railway environment database URL and sticks it into your .env file. And then this will be a database I'll tear down after this.

00:27:57 - Anthony Campolo

So no worries on the keys or anything like that. But this is just setting the database URL as an environment variable that is being read in here. And then when we deploy this, this is the only environment variable we need to feed our — whatever our Jamstack front end is — to get it connected to the back end.

00:28:15 - Ishan Anand

Now, is there a command you could run to create the model or did you have to start with that schema?

00:28:22 - Anthony Campolo

So yeah, that's basically the hard part — everything is based on the model. You start by writing the model and then all the other commands spin out from this. We're going to run a command that's going to generate an entire admin UI dashboard based on this model specifically. So knowing how to write a Prisma schema is a thing you kind of have to learn once you want to go beyond what the tutorial covers. Because the tutorial starts off with a post model, a user model, a contact model — so you have the kind of base models you need to get most things started. If you want to just turn the post into a to-do, you can do that very easily. But beyond that, that's when you start digging into things like Prisma and what the Prisma schema is doing. And honestly, this is important to point out: you don't need to use Prisma or the API folder at all. I can delete this API folder and this front end will keep running. So you don't necessarily have to learn all this stuff if you just decide you want to drop it, but it's already there.

00:29:24 - Anthony Campolo

And it's built in. This is kind of the conventions we've decided to build on, because going back to Rails and ActiveRecord, having that ORM is a thing you want to build around.

00:29:35 - Mark Mercato

Got it. Then how do we start? Let's say we want to build the post page. How do we pull that data into the actual page? When we run to the HTML, that'll

00:29:44 - Anthony Campolo

be the cell part. Let's first do the migration and then we'll get into the cells. So right now I'm running this yarn redwood prisma migrate dev command and all this is doing is taking Prisma migrate dev and running it through the Redwood CLI. This is what I mean about being able to use Prisma and know kind of how it works, and then actually figure out where Redwood's boundaries are and where Prisma's boundaries are. But for the most part, you don't really need to think about it too much — it kind of just handles it for you. And then going back to what I was saying about generating the admin UI, this is what the generate scaffold command is going to do. This is going to do everything in terms of giving us the CRUD capabilities and all that kind of stuff. So we got all that set up

00:30:37 - Ishan Anand

Actually, I needed to create the Prisma model first before running that scaffold. Is that correct?

00:30:43 - Anthony Campolo

Yes. That was essentially the only code we put in here. And if we wanted to, we could have just left the user example model there and then run a scaffold based on that. So you can take the one that's already given to you. I just like to kind of change it to like a post. This is essentially how the tutorial has you do it. So this is where the magic now really is. So this is our whole admin ui. We have no posts and it's letting us know we have no posts. So we can create a post. This will be JavaScript jam. And then now you've got your post and if you want to, you can edit it and you can also create a post that you will then delete and it'll ask you sure you want to delete it? So it does all the stuff you'd expect an admin UI like this to do, but it is doing it directly into your database. So if we go back to our database over here and look in the data, we'll see that. Am I attached to a different database? Yeah, I created two of these.

00:31:50 - Anthony Campolo

So this is the new one. So we want to go to this

00:31:56 - Mark Mercato

one, I had flashbacks to a topic that we covered on our clubhouse meetup a few months ago about the removal of Alert and confirm. When I saw that confirm dialog come up, see if they remove that. You'll have to put in a whole UI component library just to recreate that. That is how ripple effects through time and space. Yeah.

00:32:19 - Anthony Campolo

So now we have our posts here. We can see them being written directly into our database over here. So this is basically all good to go, and then to get to your last question: how do we actually do the data fetching?

00:32:39 - Ishan Anand

Actually, before we do that, I want to highlight just a couple things that may not be obvious to the listener or viewer. Like that /posts route — you didn't have to create that. It automatically scaffolded. When you ran scaffold, it knew you had a post, it knew the plural was "posts," and then set up the route. Is that correct? The classic Rails.

00:33:00 - Anthony Campolo

And this used to cause issues for some words — this is the famous bug, the Pokemon bug. If you used Pokemon, it wouldn't know how to pluralize Pokemon, so the whole thing would blow up. But we've worked those out, thankfully.

00:33:16 - Ishan Anand

Critical route name there. Okay, but so it's the scaffold. It's basically set up and you don't have to do any of this ui. All of that was again set up for you. And the code for this admin interface is, I assume, files that got populated in here we could go and modify if we wanted to.

00:33:34 - Anthony Campolo

Yeah. If we went back into our components, we now see we have all these components — post, post form, posts, post cells. And so the cells part is what we really want to kind of explain. Okay, this is the last really important key convention you need to understand in Redwood. So a cell is how you do your data fetching. The data fetching is basically how you access the database and then render it in some sort of React component. This is where some of the GraphQL stuff starts to come into play, because what we're doing here is writing a GraphQL query right at the top — we're going to do a query called posts. And then we're going to have multiple states that our post could be in: loading, if we're waiting for the data to load; empty, if there is no data (like when we saw our dashboard had no posts and it gave a different message saying "do you want to create a post?"); failure, if you have an error; and then success, when you actually get the data and it works.

00:34:42 - Anthony Campolo

So if we just import this current cell as it is, we're only going to see the ID because that's all our query is asking for. So let's first look at that. We're going to just import a component and then render the component out here. And if we go look at our front page, these are now those three posts that we created. We see we're missing ID 2 because I created a post, I deleted a post. Now if we go back to our cell, we can say, okay, I want to see more data — I want to see the whole post actually, the title and the body and when it was created. And now we're actually getting all the data there. The last thing is, okay, I actually want to make it look nice, make it look at least a little bit like an actual blog post, so I can then style it. And so I'm going to write this little success component here that's just going to map over the posts, give me the title in an h2, give me the body in a paragraph, and then give me a nice semantic time tag.

00:35:43 - Anthony Campolo

And then now that is our posts. So this is the blog. It's now essentially complete. If we wanted to add routing parameters, we could do that. If we wanted to add authentication, we could do that. Those are the next kind of steps in the tutorial. And if you want to create a contact form, you can do that. But I'll take just a couple more questions and the last thing I want to show is how to deploy this.

00:36:03 - Ishan Anand

Yeah, I just want to highlight again for the viewer. Basically, you specified the query and then you exported some end states — success, failure — and then you handled detecting where in the lifecycle that request was at.

00:36:20 - Anthony Campolo

And you can see the loading flashes a little bit there when you refresh.

00:36:24 - Ishan Anand

Oh, yeah. So you take care of all that for somebody. They don't have to worry about it. You just describe in each of those scenarios what happens. And then the framework, like a classic framework, make sure it's wired up appropriately. So you take that job off the developer, which makes it easier.

00:36:40 - Anthony Campolo

Yep, exactly.

00:36:43 - Mark Mercato

What is it like to start to tweak that query? Like if you wanted to limit the output to the top two posts or if you wanted to filter the post in some way.

00:36:50 - Anthony Campolo

Yeah, Redwood pagination — we have a cookbook for that. So if you're curious about the Redwood take on pagination, we got that as well. Beyond that, anything you can do in GraphQL you can do in Redwood, because it's just using a GraphQL client and a GraphQL server. So that kind of just gets into the question of, if you want to really tweak that query and get into the more nitty-gritty, what is your GraphQL level of knowledge? And do you know how to do that within GraphQL? You can do a lot of things within GraphQL — it's just a matter of digging through their docs to figure that out.

00:37:28 - Mark Mercato

Got it.

00:37:32 - Anthony Campolo

Cool. So now this is going to be our deploy command: yarn redwood setup deploy netlify. You could also change this to Vercel or Render or the Serverless Framework, and we're going to have another one for Fly.io in the near future. So tons of ways to deploy it. And this will create a Netlify TOML that's specifying the build command, the publish directory, and then your Netlify Functions, because your whole API folder ends up deployed as one giant Lambda function that stitches together your schema, your DB, and your services and all that. And your services — which I didn't really talk about at all — this is how you're actually talking to your database. We're getting kind of low on time here so I can't go into that too much, but this is like the controllers in Rails, essentially.

00:38:23 - Ishan Anand

So you're deploying, just to be clear for folks, you're deploying the front end and then the serverless code, but the database is still on railway.

00:38:33 - Anthony Campolo

Yeah, correct. That is the one thing that makes Render a very interesting deploy target, because Render is the only deploy target we have — and I guess AWS [unclear] works all in one place — in the sense that Render can run your front end and your server code, whether that's serverless functions or an actual server, and it also gives you a Postgres database. So no other service I know of right now is able to do all of that together, unless you're also putting the whole thing in a container in the first place, in which case it makes it a little bit simpler. Okay, so now, do you know if

00:39:09 - Mark Mercato

there are any issues around? Sorry, go ahead.

00:39:14 - Anthony Campolo

Yeah, I was gonna say, now all we gotta do is create a git repo, connect to Netlify, and this will take a little bit of time to actually deploy. Feel free to keep asking questions while I do this.

00:39:26 - Mark Mercato

Yeah. Do you know if there are any issues around using serverless functions — like running in something like Lambda — connecting to a Postgres database? One of the things I've heard is that at scale, all those different functions spinning up create a lot of connections that can overwhelm a Postgres database. And then there are workarounds for that, like RDS Proxy in AWS. But is that a thing that's mitigated at all by the framework or any of these services like Railway?

00:39:57 - Anthony Campolo

Yeah, you hit on quite the huge issue actually, which is that for the most part, things like Postgres and serverless functions don't play well because each function owns a whole connection and it just isn't easy to scale across a lot of connections all at once. Now there are a lot of companies working on this. Supabase has PG Bouncer built in now by default, which would be the main thing you want to handle this problem. The problem is Prisma doesn't yet work with PG Bouncer, so they're still kind of working through some issues on that. And this is why we still don't really say Redwood is 1.0. Because there are a couple of little things here and there that you can work around, but it is kind of a little bit more time and effort you have to take to do it. You can figure out ways to make all this work — it's just not yet as nice and simple as everything else I'm showing. Once you get to scale, there are gonna be some things like that you have to worry about.

00:41:00 - Anthony Campolo

But this is also why we've made it very easy to just run the thing on a friggin server. If you just want to run Redwood on a server instead of a serverless function, you can do that. There's a lot of ways to do that now. So if you're gonna get to the point where you have to hack your database so much to get your serverless functions to work with it, then just bail and put the thing on a server and it's gonna be fine.

00:41:20 - Ishan Anand

Yeah, it's kind of like this is the thing about serverless. It's kind of like, you know, trying to get the wrinkle out of a carpet. It's like you push it away and you're like, oh my. Serverless can scale now. But it's like, no, you've just caused it to pop up somewhere else. So definitely worth. Keep in mind. Go ahead. Mark. Sorry.

00:41:38 - Mark Mercato

Do you know specifically if RDS proxy is a solution for this?

00:41:43 - Anthony Campolo

RDS Proxy would be one of the main things you want to look at for this. The problem is we don't have any docs for that yet. We don't really have anyone on the team who's an RDS Proxy expert who's already taken a Redwood app, connected it to RDS Proxy, and mapped that whole path for everyone else. So someone just needs to do that at a certain point. These are the types of things I usually kind of pick off as the months go on — I just pick some random Redwood topic. That's why I learned how to deploy to Fly.io with a Docker container just a couple weeks ago. So we'll get there eventually, and if you're determined enough and you're someone who knows what these things are and how they work, you could probably figure it out yourself. But right now there's not really a Redwood solution to using RDS.

00:42:25 - Ishan Anand

Mark, should we explain what RDS proxy is to folks?

00:42:29 - Anthony Campolo

Yeah, definitely, yeah.

00:42:31 - Mark Mercato

It's basically like a connection pool as a service that you can put in front of rds, which is Amazon's relational database service. Basically they host Postgres for you. So it, you know, it limits the amount of connections that need to come into Postgres and essentially solves this problem because you know as your traffic goes up you can have essentially as many lambdas as you're willing to pay for and so you can have quite a few connections. So RDS proxy is just a connection pool.

00:42:58 - Ishan Anand

So maybe that's a good segue to: how far are you guys to 1.0? When can folks use this in production? What are some high-profile apps maybe live today on Redwood? How long till 1.0, what should folks be aware of if they're going to try it, and what are some good examples?

00:43:24 - Anthony Campolo

Yeah, definitely. So we have been cracking away at 1.0 for a long time and we're extremely close — we're just going to be one or two minor releases away from a release candidate. The release candidate will be coming within the next couple months, and that will be what people iterate on and test, and then that will be what will become 1.0 without any breaking changes from the release candidate to the main one. And then the actual 1.0 production will likely be beginning of 2022. But there are a handful of companies already using it in production. Everfund is one of the most well known — this is my co-host on FSJam, Chris's company. It's a donations link platform where you can basically create different links that you can then put on your own website for the specific UK tax aid [Gift Aid?] kind of thing. And then User Vitals by Tharshin. This is a tool for getting feedback from users and from people using your product. There's always this problem of people using your thing, it breaks, and then they never use it again and you never find out about it.

00:44:31 - Anthony Campolo

So how do you actually close that gap — something's wrong, how do you get that information to the team so they can actually fix it and make it right? So those are two. There are actually a lot more. If you go to the Awesome RedwoodJS repo, you can find a decent chunk of production Redwood applications. Tape.sh is another big one — this is a screen recording tool that has a UI and a CLI. And then repeater.dev — both of these are from core team members on the Redwood team. Repeater is like a background job processing thing for Jamstack, for all the things you need to have a queue or a persistent server running for — that's the main thing you can't really deal with in Jamstack. So it's a solution for that. So lots of things already using it. But I would say if you're interested in Redwood and you want to build something serious with it, you should start testing it now with the plan of deploying at the beginning of next year. Okay, so this thing is live now and the last thing I want to do here is just give us a nice little domain name — "redwood" — and then if we go to this link, we'll actually be able to see those posts that we created here.

00:45:52 - Anthony Campolo

Now the issue here of course is that this is just a live database. Anybody can go in and edit and delete and mess with it. So I skipped the authentication part of the tutorial, which is very, very important. But this is kind of the end-to-end experience of what's happening here and how to do the whole thing.

00:46:10 - Mark Mercato

Gotcha. That's an interesting segue. So I assume there's like an authentication module built into Redwood or do you use a third party thing? How does that choice work?

00:46:20 - Anthony Campolo

We give you the option to use like seven different third-party things, so it's gotten a little bit out of hand how many different ways you can do auth with Redwood. If you look at this list: Netlify Identity widget, Auth0, Azure, Clerk — most people don't even know about GoTrue, which is the underlying auth server of the Identity widget. Magic Links is a whole different company. You can also do Magic Links with Supabase, you can do it with Ethereum so you can attach to a blockchain. Magic Links is also on a blockchain. You can do it with Firebase, you can do it with Nhost, and you can also build your own.

00:46:51 - Mark Mercato

Gotcha. Okay, cool. So maybe to finish out here, there's a few other competitors in this space where they're all upstarts. You have Blitz, you have Bison and Redwood. Js, I think, are the three big ones vying for the Full Stack framework space in JavaScript. What do you know about those others too? Bison and Blitz. And how would you compare them to Redwood?

00:47:14 - Anthony Campolo

Totally. I think I've probably been the biggest Bison advocate there is. I've been telling people about it forever and almost no one even knows what it is. So it's another example of a full-stack React framework that uses GraphQL. Now that makes Bison more comparable to Redwood than Blitz, because the important thing about Blitz is that it does not use GraphQL — it doesn't even have you build an API, period. And this is why it's seen as an even better rapid prototyping tool than Redwood, because you can build something even faster if you're not building an API. So that is the one thing that makes it really nice for people who just want to write essentially front-end code that calls functions directly into their database and doesn't deal with this whole GraphQL nonsense. Because as we talked about in the demo, the GraphQL stuff comes into play as you're writing your queries, setting up your models, all sorts of stuff. But they all are using React and they all are using Prisma. So that's the interesting underlying layer between all of them — Prisma is a very important key initiator of this movement.

00:48:22 - Anthony Campolo

Because having an ORM that people are finally happy with in JavaScript is what allowed people to build these full-stack frameworks. So if you want to look at what's similar between all of them: they all use Prisma, they all use React. The difference is some of them use GraphQL, some of them don't. And then there are final questions of how they handle CSS, are they using React Query or Apollo — and those are kind of more nitty-gritty questions that are less important than the core thing, which is how do you feel about APIs? That's going to define which one you end up picking.

00:48:53 - Ishan Anand

So if you're trying to decide between them, it's do you Want to know GraphQL or not? Are there other criteria that are important to.

00:49:01 - Anthony Campolo

No, it's do you find the concept of creating an API valuable or time-saving? It's a philosophical question. How do you feel about the entire concept of APIs? So if you want to very easily stick another client on top, then Redwood's going to be nice because you have a GraphQL API and GraphQL set up to be decoupled from the front end.

00:49:21 - Ishan Anand

So it's easier to add like a native app or something.

00:49:25 - Anthony Campolo

Exactly. Yeah. But if you don't want to deal with that and you know you want a monolith because you're building a monolith and build a monolith. So that's when you would use, use Blitz.

00:49:33 - Mark Mercato

Got it. What about subscriptions, real-time streaming data? In Rails they added that in the last few years. And I know with Apollo Client you can have subscriptions to GraphQL queries. Is that provided by Redwood?

00:49:49 - Anthony Campolo

Yeah. So the subscriptions question is a little complicated because it's: are you implementing that in the front or the back end, or some sort of unified flow between the two? Because you can set up subscriptions with Supabase, but if you're not using Supabase then you can't use Supabase subscriptions. So then you have to implement it in the actual GraphQL server that you're building. You can do that, and then either way you have to figure out how the subscriptions are going to get into the front end. So that's another thing that is possible — people have done it — but there's not really great docs around it yet. So that's another thing we're kind of honing as we get to 1.1.0. We're working very closely with the Guild, which is the group that Yuri [unclear: Uri Goldshtein?] runs. He's kind of the guy who originally created Apollo back in the day, and now has left Apollo and is now leading this decentralized group of GraphQL consultants that build open source projects. It's really interesting stuff. You should get them on the podcast.

00:50:48 - Anthony Campolo

But they're helping us a lot with this more nitty-gritty stuff — how do you do subscriptions and GraphQL subscriptions and live queries and this whole philosophical debate around that. So that's a deep technical question that there's a long, long Redwood issue about if you are curious about it. But it's kind of a niche thing.

00:51:07 - Ishan Anand

All three of these frameworks have Rails opinions, the conventions they keep you on. Maybe you don't know the answer to this, but if you were to break off from the Rails and decide you need to go off on your own direction, is one of the three easier than the other to say, gives you more of that flexibility to be less opinionated in the using of the framework.

00:51:32 - Anthony Campolo

So if you want to eject from the framework effectively.

00:51:34 - Ishan Anand

Yeah, think of it like eject. Yeah, yeah.

00:51:37 - Anthony Campolo

I think Redwood is set up pretty well to do that, because the front and the back end are already decoupled from each other. If you wanted to drop the API layer and the database, you can do that and then you just have this React front end essentially. But if you want to drop the website and then build some sort of Vue app because you just need to make GraphQL queries from your Vue front end, you can do that as well. So I think that would be the easiest one to eject from. For the most part we don't really think you should have to do that — the whole point of the framework is to not need to eject, so we try to cover all the edge cases so you wouldn't need to. But I do think it actually has a pretty good story there. When I was first getting into Redwood, I built a prototype with Fauna. FaunaDB doesn't work with Prisma at all — they have no compatibility whatsoever — so you were entirely dropping that and then writing FQL queries that your services were calling.

00:52:29 - Anthony Campolo

And you can do that. It was possible. I was able to figure out how to do that. So there's a pretty good eject story for Redwood. Even though we say you probably shouldn't if you need to, you can definitely do it. Now, I don't really know Blitz well enough to know what the eject story is for them, but I would guess they would probably say the same thing, like you shouldn't need to eject from Blitz, because that's like the whole point.

00:52:49 - Ishan Anand

It seems like, from what I've gathered of both frameworks, my gut feeling is that it might be a little easier in Redwood because, as you put it, everything's already decoupled and it's decoupled according to a well-known standard. It's probably possible in both, to be fair. So yeah.

00:53:07 - Anthony Campolo

Cause it's still just Prisma and a react front end, so it's the same thing, you know.

00:53:11 - Mark Mercato

So then segue to our last question, which is talk about roadmap. What are you excited for in the future of RedwoodJS?

00:53:18 - Anthony Campolo

Yeah, I've been really excited for the Docker deploy story, funny enough, because I barely knew anything about Docker two or three months ago and I've been slowly learning how it works because we're trying to figure out how to Dockerize Redwood — give a good Redwood convention around that. So that's something I've been personally involved in, getting it deployed to Fly.io and stuff like that. It's really cool interesting stuff. Everything that happened around just switching out Apollo Server for GraphQL Helix was really fascinating to watch. And that's pretty much over the finish line with this last release, so that's not really a future thing anymore. But that's something that most people still don't really know about, and I think it's really interesting. But at this point it's just about polish. We just want to make sure that all the bugs are covered, all the docs are up to date, and whatever you want to do works — make sure Windows works correctly. It's more of the nitty-gritty nuts and bolts now. Just make sure it works in every situation.

00:54:17 - Anthony Campolo

So there's not like cool features coming anymore. That's not what people want. People don't want more cool features. They want the thing to be 1.0, you know.

00:54:25 - Ishan Anand

Well, to wrap it up, where should people go to get started with Redwood and learn more, and where should they go online to find out more and hear more from you?

00:54:38 - Anthony Campolo

Absolutely. Redwoodjs.com — that's where everything is. From there you can find links to our Twitter, our Discord, or our Discourse forum. I love the Discord, I hang out there all the time, and I really love the Discourse forum as well. So if you're someone who wants to get involved in an open source project, there's a huge team of people waiting to help you out and give you guidance. We really recommend anyone who thinks this sounds interesting should just hop in and start building stuff with us. And then myself personally: I am AJCWebdev everywhere — Twitter, Dev.to, GitHub, all those areas. And I host FSJam. So fsjam.org is where you can find that podcast, and that should be all the places I reside online. Thank you guys so much for having me. This was really great. I haven't given a Redwood demo in a while — I used to do these like every week last year when I was doing meetup talks for Redwood constantly. But it was fun to get to do one again.

00:55:39 - Ishan Anand

Yeah. Thank you for coming on. We enjoyed having you. And thank you everyone for tuning in. We will see you at the next episode.