Does Not Compute on RedwoodJS with Anthony Campolo
Anthony Campolo discusses RedwoodJS, a full-stack framework utilizing GraphQL, React, and serverless functions
Episode Description
Anthony Campolo joins DNC Cast to explain RedwoodJS, a full-stack Jamstack framework combining React, GraphQL, and Prisma for building scalable apps.
Episode Summary
Anthony Campolo, core developer advocate for RedwoodJS, joins Sean Washington and Rockwell Schrock to break down what Redwood is and why it matters for developers struggling to stitch together modern full-stack applications. The conversation begins by defining the Jamstack and its limitations — particularly the lack of a database — before explaining how Redwood addresses this by combining a React front end with a GraphQL-powered API layer backed by Prisma and a relational database, all within a single monorepo. Anthony draws frequent comparisons to Rails, noting that Redwood co-creator Tom Preston-Werner built GitHub on Rails and designed Redwood to offer that same convention-over-configuration developer experience using modern JavaScript tooling. Sean shares his own frustrations managing multiple services like Firebase, NextAuth, and Heroku, illustrating exactly the fragmentation problem Redwood aims to solve. The discussion covers Redwood's deployment targets, its relationship to competing frameworks like Blitz, the concept of "headless Redwood" with a Next.js front end, the roadmap toward version 1.0, and the practical limits of running a monolithic GraphQL handler inside a single Lambda function. By the end, the hosts are persuaded enough to commit to building something with Redwood themselves.
Chapters
00:00:00 - Introductions and What Is Jamstack
The hosts welcome Anthony Campolo, RedwoodJS core developer advocate, and mention his podcast FSom, which covers full-stack Jamstack applications. Anthony explains how he earned his role by simply doing the work of advocacy — writing blog posts, giving talks, and doing podcasts — until the team formalized his position.
The conversation establishes a baseline by defining Jamstack as a paradigm built around static assets deployed to a CDN, using tools like Gatsby, Next.js, Netlify, and Vercel. Anthony explains that while this approach handles global distribution elegantly, it traditionally lacks a database, which limits what developers can build. The central question of "full-stack Jamstack" becomes clear: how do you get a powerful back end while preserving the simplicity of git-push deploys and CDN distribution?
00:05:47 - Redwood's Architecture: Monorepo, GraphQL, and Prisma
Anthony walks through Redwood's monorepo structure, which splits into a React-based web folder and an API folder containing GraphQL schemas and Prisma-powered database logic. He explains the generator commands that scaffold pages, layouts, and services, drawing parallels to the Rails workflow that inspired the framework's design.
The discussion turns to Prisma as Redwood's ORM, its relational-database-only approach, and the deliberate separation between the Prisma schema and the GraphQL SDL. Anthony explains how this decoupling allows swapping databases — Postgres, MySQL, or SQLite — without affecting the GraphQL layer. He also touches on the distinction between Prisma 1 and Prisma 2, and contrasts Redwood's GraphQL-centric approach with Blitz's RPC-based model, highlighting that the choice of data layer communication is a key architectural differentiator among these newer frameworks.
00:10:48 - The Pain of Stitching Services Together
Sean shares his real-world frustrations building a project with Next.js and Firebase, detailing problems with NextAuth session management and the headache of juggling multiple services, dashboards, and billing accounts. Anthony validates these pain points, explaining that Redwood and similar frameworks offer tiered auth solutions — from fully managed options like Netlify Identity down to raw JWT handling.
The conversation broadens into deployment targets, with Anthony listing Netlify, Vercel, AWS serverless, Render, and Begin as front-end options, plus Heroku, Azure, and Supabase for databases. He articulates the ultimate goal: collapsing front end and back end into a single deploy target with one dashboard. Sean recounts his own failed attempt at deploying a Rails API to DigitalOcean's app platform, reinforcing how even experienced developers get stuck on deployment friction rather than building their actual applications.
00:16:25 - Redwood's Tech Stack Decisions and Philosophy
Rockwell steers the conversation back to Redwood's core architecture, and Anthony explains the dual-schema setup — a Prisma schema for the database and a separate GraphQL SDL — and why this apparent duplication actually enables flexibility. The discussion touches on database-as-a-service tools like Supabase and Hasura, and Sean notes the expertise barrier of becoming a de facto database admin when using views and advanced Postgres features.
Anthony articulates Redwood's design philosophy: enabling solo developers to build powerful applications without being experts in every layer. He outlines the framework's guiding principles — convention over configuration, relational databases over NoSQL, serverless by default, and a monorepo structure. The hosts discuss how the quality of Redwood's documentation and tutorial signal maturity even before a 1.0 release, and Anthony connects this to Tom Preston-Werner's legacy of README-driven development and the creation of Jekyll and GitHub Pages.
00:25:49 - Roadmap, Testing, and the Path to 1.0
Anthony sets the historical context for Redwood, tracing its origins back to 2018 when Tom Preston-Werner and Peter Pastorius were building a React-and-GraphQL front end against a Rails back end at Chatter Bug. He explains that the framework launched publicly in March 2020 and is targeting a 1.0 release roughly a year later, with current work focused on Storybook integration, Jest testing setup, and data mocking.
Sean connects deeply with this focus on testing infrastructure, sharing his own experience of trying to set up tests for a Prisma-based project and getting lost in decisions about mocking, seeding, and tooling. Anthony emphasizes that for newer developers, the barrier is even higher — they may never ship anything at all without framework-level scaffolding. The discussion reinforces that Redwood's generator commands produce test and Storybook files out of the box, aiming to make TDD the default rather than an afterthought.
00:32:55 - Redwood vs. Gatsby, Next, and Blitz
Anthony addresses the most common question he receives — why use Redwood over Gatsby or Next — with a simple decision tree: if you need a database and user authentication, Redwood is the answer. He then contrasts Redwood with Blitz, explaining that Blitz brands itself as a "full-stack React framework" while Redwood uses "full-stack Jamstack," and these labels reflect real architectural differences around serverless deployment versus monolithic servers.
The conversation explores the concept of "headless Redwood," where developers use Redwood's API layer but swap in Next.js for the front end to take advantage of its more mature rendering optimizations. Anthony candidly acknowledges that Redwood's web side is still catching up to four-year-old frameworks like Next, and discusses real production apps including Ever Fund, Tapesh, and Repeater.dev that validate the framework in real-world scenarios.
00:41:00 - GraphQL as the Core, Cells, and TypeScript
Anthony argues that GraphQL — not React — is the true core of Redwood, explaining that you could theoretically swap in Vue on the front end but removing GraphQL would fundamentally change the framework. He compares Redwood's architecture to AWS AppSync with DynamoDB and Lambda, then introduces the concept of "cells" — Redwood's declarative data-fetching components that handle loading, error, empty, and success states automatically.
The discussion shifts to TypeScript support, which Anthony confirms is actively being converted across the framework. Questions from the live chat prompt brief tangents into Flutter compatibility, React Native plans, and the possibility of Vue or Svelte front ends, which Anthony considers unlikely due to tight coupling. He also touches on micro-frontends, WebAssembly's potential future role, and the practical reality that the headless Redwood approach is the most reasonable path for non-React developers.
00:49:09 - Lambda Limits, Production Apps, and Closing Thoughts
Anthony explains the current technical limitation of running Redwood in production: the entire GraphQL handler gets bundled into a single Lambda function, and Lambda has size constraints that weren't designed for this use case. He describes how some developers are working around this by running Redwood on traditional servers with PM2, essentially making a serverless framework "serverful."
Rockwell highlights the appeal of Redwood for hobby projects — minimal infrastructure, near-zero cost, and no ongoing maintenance beyond the database. The episode wraps with Anthony sharing his online handles and encouraging listeners to reach out, while Sean and Rockwell commit to trying Redwood themselves and invite Anthony back for a follow-up episode with real-world impressions. The conversation closes with community plugs for the DNC Discord and next week's mystery guest.
Transcript
00:00:08 - Sean Washington
This is the first stream of the new year. Yeah.
00:00:11 - Rockwell Schrock
Yes. Happy new year, Sean.
00:00:16 - Sean Washington
Happy New Year, everybody.
00:00:18 - Rockwell Schrock
And happy new year to Anthony. Hello, Anthony.
00:00:22 - Sean Washington
Yeah. Hello, Anthony. Welcome, Anthony. Mr. Anthony Campolo to the show. He is a core team member of the RedwoodJS effort, which we'll be talking about. We have a lot. We have many questions for you, Anthony. So get ready.
00:00:35 - Rockwell Schrock
So many questions.
00:00:36 - Anthony Campolo
That's good. That's what I love doing.
00:00:38 - Sean Washington
I also just wanted to mention he also has a podcast called Fsom where they talk about full stack Jamstack applications.
00:00:44 - Rockwell Schrock
Putting that plug right at the top. I like it.
00:00:47 - Anthony Campolo
Yeah. So that's kind of this whole area of frameworks, because we'll get into this, but Redwood is one of many different ways of combining all these technologies.
The idea of that podcast is to talk about Redwood, but also other projects that may be similar to Redwood or different from Redwood, but aiming for similar goals. It's like building community around this new full stack thing that we're all working on.
00:01:14 - Rockwell Schrock
So, Anthony, you're the core developer advocate for the RedwoodJS team. Why don't you tell us a little about yourself and how exactly you ended up in that role? Because that's something you don't really see very often, at least not in our friend circles.
00:01:28 - Anthony Campolo
Yeah, it's one of those things where I ended up in the role by essentially doing it, and then eventually they had to give me the title because I was just doing it.
So essentially, a developer advocate is someone who goes out and explains or teaches or demonstrates a piece of technology. So what I do is I do meetup talks and I write blog posts, and I do podcasts such as this to basically tell people what Redwood is, how it works, and how to leverage it. What you actually should use it for. What you shouldn't use it for as well. And all that kind of stuff.
So I started doing this back in June. And as the project grew and I was kind of like the only person doing it, it eventually got to the point where they were going to create more of a formal structure around the project. And so they asked me to join the team as the official core advocate.
00:02:24 - Rockwell Schrock
That's cool. They make a position for you because you're already doing it. That's awesome. Since you're going to advocate for RedwoodJS, why don't you tell us about it?
00:02:33 - Anthony Campolo
Yeah, totally.
00:02:34 - Rockwell Schrock
So Sean and I, we have a very surface-level understanding of Jamstack. I've never tried to write any Jamstack-style applications. Have you, Sean?
00:02:45 - Sean Washington
No, certainly not. Like, full-stack Jamstack. But I've done a lot of static stuff. I don't know if that is considered Jamstack.
00:02:54 - Rockwell Schrock
Yeah, we have GraphQL, React, and that static site generation experience client side, but not so much the serverless functions or any of that other stuff.
00:03:04 - Sean Washington
Right.
00:03:04 - Anthony Campolo
Yeah. So let's kind of first define Jamstack. And then we can kind of go into how that relates to full stack Jamstack.
So you kind of need that first context. When people say Jamstack, it's like you say, it's a static site, is really essentially what it is. So if you've ever used Netlify or Vercel and you've worked with something like Gatsby or Next.js, all of this is kind of in that Jamstack area.
And the idea is that you're generating just a bunch of static assets that are being deployed to a CDN. So the CDN part is really important here, because that's what gets it globally distributed. And you don't have to deal with a single server running in US East 1 or wherever. And that's what's really nice about the Jamstack paradigm.
Now, the problem, though, is that traditionally you don't have a database, and so you can't do a lot without a database. And if you really want to have a full application with users and authentication and all the stuff you want to do and the types of apps you want to do, you need that back end.
00:04:09 - Anthony Campolo
But the question of full stack Jamstack is, how do we get that back end while still being globally distributed with this super nice git push deploy kind of paradigm that we've built up in the Jamstack?
00:04:21 - Rockwell Schrock
Yeah. Having a CDN, I mean, you mentioned US East 1. Just saying that sends shivers down my spine, like having to manage that infrastructure.
Well, I guess what's the most magical part of this is sort of the back end stuff? Because I think the front end frameworks like Next and Nuxt and just React in general, people are pretty familiar with that paradigm. But having it under one repo is kind of cool. I think that's the whole thing, right?
00:04:50 - Anthony Campolo
Yeah. So you definitely have the right context then to kind of get this. So it's not doing anything revolutionary in the sense that it's really kind of taking those ideas of what you're talking about and those frameworks, and giving you nice conventions to attach it to the back end.
Because lots of people are building all these applications where they're figuring out how to wire up a Heroku Postgres database and all this kind of stuff. They may be using TypeORM, they may be using Sequelize, they may be using Prisma, which is what Redwood uses. So there's all these different tools. And the idea is: how do we integrate these tools in a really nice way to give you a Ruby on Rails type experience, but with this new technology?
So going back to what is the technology in it, let's just break this down. The front end is just like a React app.
00:05:47 - Anthony Campolo
So it's very much like a Create React App or a Next thing. It has pages and layouts. It has a folder structure for your front end project. But then it also has an API folder.
So, as you're saying, it's a monorepo. So it's one big project that has two folders in it. One is your website and one is your API side. And the API side is where you got all your GraphQL stuff going on.
So what's your guys' experience level with GraphQL? Do you know schema definition languages? That's kind of the main thing. The schema definition language is just how you define your types in your back end. So if you are creating a blog, you're going to have blog posts and you're going to have a type post, and that type post will have an ID with an auto incrementing integer. It will have a title, it'll have a body, and it'll have a created at date.
00:06:43 - Anthony Campolo
And then you have Prisma integrated. So you can just run commands that will generate your SQL. They'll do your SQL commands, they'll set up your back end for you.
And if you're someone who's really more into relational databases than this whole Mongo thing, Redwood is actually really nice for you because it's entirely relational based, because Prisma at this point doesn't work with Mongo. We're going to get there in two to three years maybe, but as of now, it's entirely relational.
00:07:13 - Rockwell Schrock
Do you really want to though?
00:07:16 - Anthony Campolo
Do you really want to use Mongo?
00:07:19 - Rockwell Schrock
I guess some people do.
00:07:21 - Anthony Campolo
Well, some people only use Mongo because they never learned relational, because some people are brought up in this whole NoSQL paradigm and they don't know any better.
00:07:30 - Sean Washington
You're speaking my language here, Anthony. Yeah. I don't know if you know that.
00:07:34 - Anthony Campolo
No, totally. And this is why I originally reached out to you. It's what kind of led to all this, because I was listening to your conversation. It was the Mongo adjacent episode, and there were two ideas you were spinning around that weren't quite connected in the conversation. And this is something that I'm noticing now.
I'm noticing people who are rebuilding Redwood in their own kind of way. And so you're talking about having Heroku Postgres, or just Postgres in general, as this universal back end. And you're also talking about writing your whole back end as serverless functions. And that is Redwood in a nutshell. Your back end is serverless functions that are being mapped with a GraphQL schema to a relational backend, which is Postgres.
00:08:18 - Sean Washington
Okay. So, okay, I still have questions here. So basically, in a nutshell, to make sure I have this right, you got Redwood as an umbrella and it's kind of split up into two projects.
You have the API side, which would be like your data layer, your database, whatever other services you need to connect to. And you use GraphQL to kind of schema stitch everything together and expose it in a unified front, similar to maybe Gatsby or Gridsome or one of those other tools that connects to many databases and exposes one API for you to use.
And then you have the front end side of things, which is more or less a React app. After looking at some of the docs, it seems like there's helpers or utilities you can use, basically like things that help reduce the amount of reactive boilerplate you have to write.
00:09:06 - Anthony Campolo
Yeah. So there's generator commands that map very nicely to your project structure and then other things you need to create. So if you want to create pages, you have a generate page command. If you want to create layouts, you have generate layout command. If you want to create your back end services and talk to your APIs, you have generate services command. So for someone who watched the Rails demo back in the day, a lot of the stuff should resonate there.
00:09:30 - Rockwell Schrock
Yeah. So we'll put a link in the show notes to your talk you just recently did for JS Monthly.
I skimmed through that. I did my homework at the last minute. I watched it literally just before he came on the air here, and I got very much that real feel of like watching you just do the generators and stuff. It kind of did bring that back.
00:09:50 - Sean Washington
Cool. So the whole Mongo adjacent episode happened, right? And then I got mad at some stuff I was working on, and I just said rails new into the console and suddenly I had generated an application, an API that was done. On the API side, it was just done. Suddenly it was just done.
And that's really the experience that I'm missing on the whole front end side of things. Like, I understand the power of serverless and being able to deploy your front end globally, like you said on the CDN, to all the edges, all the clouds, all the edges of all the clouds that exist.
But really where things kind of break down for me is having to stitch these services together. The closest I found to not having to do that would be something like Firebase. But then you're using Firestore, I guess. Which, you know, if you're familiar with relational, then you have to learn a new paradigm with the document database.
00:10:48 - Sean Washington
Hence the whole adjacent episode.
Another interesting thing that I've seen people do is they use Firebase just for auth or just for a couple of services, and then they spin up Postgres somewhere else. And so now you have sort of three places to manage things.
And for me that's kind of where it breaks down if I'm trying to just spin off projects on my own. It just makes it kind of a nonstarter for me because then I'm having to create multiple accounts, manage multiple accounts, manage multiple billing areas, service areas. It's a whole thing, basically.
00:11:19 - Anthony Campolo
Yeah. Firebase gets brought up a lot when I'm talking about Redwood and these kinds of services because it's going for the same thing.
I've talked a lot recently about AWS AppSync, which also has a lot of similarities. If you combine that with DynamoDB, you get a similar experience to what you get from Firebase, because you want to just have that database there that you can access and write against a nice API to do everything you want to do.
But like you said, then you might have auth as well that you want to do. But if you can't do all of that in your database and have it play nicely with your front end, then you're going to run into trouble. So it's about how do you get all that into an integrated experience that's easy to work with.
00:12:03 - Sean Washington
Yeah. That's kind of where I'm stuck now.
So the project I'm working on, I'm using Next and Firebase. I was looking at many different ways I could implement auth. I just don't want to do it, to be quite honest. I don't like implementing auth. I don't want to implement auth. And so I was like, hey, let's just use NextAuth. It seems pretty complete.
And so I had already set up username password authentication. And so NextAuth kind of discourages that. So automatically you're sort of limited in functionality there.
But also I found out the hard way that there seems to be an issue with updating the session. So if I'm trying to store like a token from Firebase in my NextAuth side of things, you basically, when someone signs in, I want to be able to augment the session and put custom data into the session or the JWT that NextAuth is creating.
00:12:58 - Sean Washington
And that's not happening. It doesn't work for me right now, and I'm finding that other people are having a similar issue on GitHub. So now I can keep banging my head against the wall, or wait for someone else to find a solution, or tear that out and just do it myself, which I don't want to do.
00:13:14 - Anthony Campolo
Right. Yeah. No, this is definitely a thing that I want to highlight, actually, as a key piece of these kind of frameworks that I'm talking about. And this is one where a similar framework, Blitz, that's another one that we talk about on the podcast a lot. They have a ton of auth integration as well.
So both Blitz and Redwood, they don't just give you an auth solution. They give you multiple auth solutions so you can integrate it with something like Netlify Identity, and that's going to do everything. That's going to give you a login form and that's going to handle everything for you.
Or you can do it a little more low level and you can do it with say like Firebase Auth. You have a little more control there. Or you can even go further and just handle all of the JWT stuff yourself. So there's different levels to do this, and there's docs to explain each of these different levels and how to do them with the framework.
00:14:03 - Rockwell Schrock
Yeah. Jumping a little ahead, but I was looking at deployment targets for Redwood and it supports Netlify, Vercel, and serverless on AWS. It's great that it supports that. The framework does support multiple integrations.
00:14:19 - Anthony Campolo
You can do more than that now. It can do Render also now, and I'm figuring out Begin right now. So it's getting close to like five deploy targets. And that's just the front end.
So the back end then is a whole different question because you can also do Heroku Postgres or you can do Azure Postgres or you can do Supabase. Like there's not only different ways to deploy the front end and the back end, and there's different ways to then combine those two.
And now the question is how do we get the front end and the back end all into a single deploy target. Because the problem is you still end up with your front end on Netlify or Vercel and your back end on Heroku or Azure, and you're grabbing an environment variable and integrating those two services. What you really want is something like DigitalOcean, where you can get your back end and your server and your front end all on a single service. So you're only managing one login, one dashboard. We just want one dashboard.
00:15:08 - Anthony Campolo
We all want Uber Dashboard to handle our whole app. Like that's what everyone's aiming at here.
00:15:14 - Sean Washington
Yeah. But I mean it sounds compelling, though, because even like when I made the Rails API and I was thinking to myself, maybe I'll try DigitalOcean app platform.
And I hook it up, I push up to git, it starts deploying, and it blows up. It blew up because there were some bundler deprecation warnings, but there weren't any docs for me to go and find out how I can fix this, or how I could go about changing whatever build packs or the build command.
So then I'm stuck there. And the only reason I really wanted to do that was because DigitalOcean is kind of one spot. If I have other servers there, it's there. My other option then is to go to Heroku, which I'm familiar with, but then two dashboards, two bills. And the same issue that I was talking about before exists. So I got frustrated with that, and I was like, all right, back to Firebase.
00:16:09 - Anthony Campolo
Yeah, definitely. And some of the things that this is kind of still in flux right now is figuring out the best way to deploy these applications. And some frameworks are creating companies and some companies are creating frameworks. So we'll see where things go.
00:16:23 - Sean Washington
Yeah.
00:16:25 - Rockwell Schrock
Well, so you were walking us through before we derailed here. You were walking us through the front end and back end split and sort of, you're talking about schemas and you're talking about GraphQL. So are there any other major pieces to Redwood that would need understanding to sort of see how it all fits together?
00:16:41 - Anthony Campolo
Yeah. So Prisma is the other big thing because that's your ORM. So it would be like Eloquent or ActiveRecord or Hibernate. Most full stack frameworks have some sort of ORM type tool. And it's just what does the SQL stuff for you.
And we'll get into the development roadmap in a second. The really cool thing about Redwood, though, is that you don't necessarily need to use Prisma, because there's been this heated debate going on for like 15 years now about whether an ORM is something that we should even use or not.
And you had this famous blog post called ORMs are the Vietnam of Computer Science. And Prisma themselves kind of refused to call themselves an ORM for a really long time.
00:17:35 - Rockwell Schrock
I gotta find that article. That sounds like some hyperbole.
00:17:39 - Anthony Campolo
Well, it's actually kind of a funny analogy when you think about it. The idea is that it seems like a good idea at the time, and then you get into it and you can't get out, but you have to keep throwing more and more resources at it.
00:17:50 - Rockwell Schrock
I love it.
00:17:51 - Sean Washington
So in terms of, okay, we're talking about Prisma now. And then you mentioned there's sort of a unified GraphQL endpoint there.
And we know that with Prisma, you have sort of Prisma's SDL language where you kind of define your schema and Prisma will make your database or your SQL schema look like your Prisma file. Do you have to have a separate GraphQL SDL as well?
00:18:12 - Anthony Campolo
Yeah, this is a fantastic question. If anyone has used Prisma in the past, the Prisma we're using now is actually Prisma 2. There was a Prisma 1 that was an entirely different tool that was very tightly coupled to GraphQL. And then they created Prisma 2, but they pulled an Angular — "we're not going to call it Prisma 2, we're just going to call it the first thing and pretend like the first thing didn't exist. And eventually people will forget about it."
And so in the first one, all the GraphQL was baked in, but now it's not. It's just an ORM kind of database tool. And Redwood is what handles the GraphQL layer.
So there is just a Prisma model and Prisma schema that has nothing at all to do with GraphQL. And so this is like going back to Blitz, another framework. Blitz uses Prisma but there's no GraphQL at all. Right. So that's kind of a key differentiator between Blitz and Redwood — they both use Prisma as their database tool.
00:19:12 - Anthony Campolo
But one is using a GraphQL API, which is Redwood, and one has nothing to do with GraphQL, which is Blitz. You're just doing function RPC calls straight into your database.
So that's kind of how you deal with that schema and how your front end and your back end really talk to each other. That's kind of the main thing. Some of these frameworks are more bought into GraphQL, like Gatsby or Gridsome, versus others that aren't as bought into GraphQL.
00:19:37 - Sean Washington
So how does that work with Redwood specifically, though? Because I assume that you do have to have the Prisma SDL for building your database schema. Do you have a separate SDL for the GraphQL services for Redwood, or does Redwood try to introspect the database or introspect the Prisma SDL?
00:19:57 - Anthony Campolo
Yeah. So your back end, your API folder splits into two. It splits into a Prisma folder and then an src folder. And so the Prisma folder is where you get your Prisma schema. And that's where all your migrations end up.
And then the src folder has your schema definition language. And it has a place where you're importing Prisma db client and writing your services in there. So that's your functions like your db.findMany kind of things. That's almost like controller logic, is how some people think about that.
So you write back end controller function logic, you write a schema, and then you also write a schema.prisma which is separate from your GraphQL schema. So you end up with two files. One is your Prisma schema, one is your SDL. It may seem like you're doing a bit of duplication there, but having your GraphQL and your database stuff separate is actually really nice because this is what allows us to work with different Postgres databases and MySQL and SQLite.
00:21:00 - Anthony Campolo
We can switch out a lot of these databases because we've decoupled all the different pieces. We've got a monolithic development workflow that is made up of decoupled pieces.
00:21:11 - Sean Washington
Right. Yeah. So some other sort of — I guess they're like database as a service. It seems like a lot of things where it's like, spin up a DB and we automatically build an API from your stuff.
00:21:24 - Anthony Campolo
Sounds like Supabase.
00:21:26 - Sean Washington
Yeah. And your API or Postgres [unclear], or something similar like that. But your API tends to be what your schema is almost one to one. And granted, Hasura and Postgres both allow you to use views. They encourage you — Postgres encourages you to use views instead of returning just straight data from your tables, because you could use views to transform it and cache things and stuff like that.
00:21:53 - Rockwell Schrock
You're talking about database views.
00:21:55 - Sean Washington
Database views. Yes. But then at that point you're basically a database admin. You have to really know the stack well. And I'm not advocating that you shouldn't, but if that's not your area of expertise, that's a pretty big barrier to entry.
00:22:10 - Anthony Campolo
Yeah. A lot of Redwood is based around enabling single solo developers to build really powerful applications because it allows you to not have to be an expert in every single layer of the stack. It's just so hard these days. And being a full stack engineer requires tools that have really put a lot of work into integrating all these pieces.
00:22:32 - Rockwell Schrock
One of the things you mentioned in your video was using a different front end framework, like using Next on the front end, and then just using Redwood for the API, serverless back end.
And that's really interesting to me because the idea of deploying, like, I like the idea of serverless functions just being a black box and being able to deploy that to multiple services. But I want to feel comfortable writing a front end framework that I already know.
So can you talk a little bit about that? Is that really a thing that's supported? What do you lose by doing that, versus going with the whole monorepo and just buying all in?
00:23:12 - Anthony Campolo
Yeah. The reason why some people have chosen to do that is because they don't feel like they're losing anything. They feel like they're gaining something because the developers who are doing that, the problem they have is that they feel that the Redwood website is currently lacking, and they're correct because Next.js is four years old and has four years of optimizations and work baked into it.
So Redwood, if you are able to leverage all the niceties from Next in terms of things like basically all the rendering stuff and like pre-rendering and having dynamic routes and all that kind of stuff, that's what you get from Next that you can do with Redwood, but you have to bring in things like React Snap. So all that stuff is not currently baked into Redwood just because you always have to make trade offs. We don't have unlimited man hours and we don't have unlimited people working on this.
So ultimately, like you got to pass the buck somewhere. And so the web part is what people find is kind of lacking.
00:24:11 - Anthony Campolo
And so they use Redwood just as, like you say, the API. So there, it's what I call a headless Redwood. So if you imagine like a headless WordPress kind of idea, you're basically just using the back end and you get rid of the front end entirely and you stick a different front end on it.
So people are doing that because Next is such an awesome front end framework and has lots of stuff baked into it that you're not necessarily going to have in Redwood just because Redwood hasn't been around as long. I think a year from now, Redwood will have all of those things in the web front end, but we're just not there right now.
It's really interesting. This is my co-host, actually, Christopher Burns on the podcast. He's one of the people who has done this for his application. So we spent whole episodes talking about this.
So, yes. Active Record is basically what Prisma is. There's a question in the chat about how Prisma relates to something like Active Record. Tom and the team specifically picked Prisma to be a sit in for what they expect a framework with an ORM to do because they have used Active Record in Rails.
So a lot of Redwood is very much modeled on Rails in that respect, because old school Rails developers have built it, and some people may know Tom Preston-Werner originally built GitHub with Rails, so he scaled one of the largest Rails apps in history. So he's kind of run into a lot of the problems that you get with Rails. So Redwood is taking influence from Rails by trying to find tools that can approximate it, like something like Active Record, but still being able to scale it in a way that allows you to not hit the sort of limitations you hit with Rails.
00:25:49 - Rockwell Schrock
Thomas in the chat also asks what the next year of Redwood development looks like, and we will post a link in the chat. There is a roadmap on the website, but you want to talk a little bit about it.
00:26:00 - Anthony Campolo
Yeah, so we are in a really exciting point in Redwood's history right now. So let me just first set the broader context of where we are because it's important to know where we've come from to get context of where we're going.
So Redwood first started many years ago, probably going back to around 2018 when Tom Preston-Werner and Peter Pistorius were working together at a company called ChattrBug. And ChattrBug was, or is, a language learning platform.
And so they were building out a React front end application that was speaking GraphQL to a Rails back end. And they were running into a lot of the issues that you run into building these kinds of applications. And so throughout 2018 and 2019, they were going back and forth saying, how can we build a framework that could accommodate this new paradigm of how we're building applications, but give us this older, nicer convention over configuration style development?
00:27:05 - Anthony Campolo
So throughout 2019, they were kicking it around. And then the repo — I think it was June 2019 — is when they started the repo. And then this year, 2020 in March, is when it actually went public and kind of launched. And that's when it was like version 0.1.
And right now we're at version 0.22, which was released today. And so the idea is we're going to hit 1.0 kind of like a year from the original launch. We're set to hit 1.0 sometime in the next couple months.
And then it's going to be about polish over the course of the year. So making sure that we have all the things that frameworks like Next and Gatsby have. So things like a nice image component and stuff like that.
And then later on is going to be basically creating mobile apps. So the idea is that a Redwood app is going to be optimized to be multi-client in the future. So you'll be able to easily stick on a mobile application because it's just going to access your GraphQL API.
00:28:07 - Rockwell Schrock
Interesting. Are there any, like you said, just mostly polish from this point to 1.0? Are there any sort of features, major architectural decisions, kind of still in flux, or is it all pretty hammered out at this point?
00:28:20 - Anthony Campolo
A lot of the work over these last couple months has been hammering down the Storybook and testing integration. So if anyone here hasn't used Storybook, it's a tool that's really nice for developing your components in a very visual way and being able to see the different states your component can be in, but it requires lots of configuration and fiddling to get set up.
And the same with things like Jest and unit testing. So it's set up now for when you're doing your generate commands. It basically sets you up for TDD and Storybook out of the box, because it generates test files and it generates Storybook files that are set up for your components.
So that's been, and then mocking is the next big thing. Figuring out how to mock data is something they put a ton of work into. And that's why the team has been working on it. I'm going to learn over the next couple of months now that it's been introduced into the framework.
00:29:19 - Anthony Campolo
So being able to make sure that we can actually test and verify that our programs work. A lot of that stuff is not really just polish. To me this is a separate layer from polish because this isn't necessarily getting your application to function, but making sure that it's working in a way that it's really going to function in the long term. So getting that stuff finished, then after that level is where the polish comes in.
00:29:47 - Sean Washington
For me, hearing that, that's really appealing because again, that's one of the other things that drives me away from wanting to kind of do this myself. And I've gone that approach.
I've made a project. I was using TypeScript, I was using Prisma for the API. And then I was really getting into it. I wanted to start adding some tests, like you said, to make sure my application is doing what I think it's supposed to do, and then I had to make all the decisions.
Okay, do I mock the SQL request? Do I set up a separate test database? Then how do I seed it? How do I destroy it? And then you have to figure out, am I using Jest? Am I using something else just to have a mechanism for this? There are so many decisions that have to be made that I'm no longer building my app anymore.
00:30:28 - Sean Washington
I'm like plumbing, right?
00:30:30 - Anthony Campolo
Yeah, absolutely. And for you, it's plumbing. For me, as a newer developer, it was, I don't even ship a thing. That's the thing is, like, for developers like you, it's like, oh wow, this is really hard. Whereas for newer developers, it's like, I don't even know how to get a thing that functions in the first place.
00:30:49 - Sean Washington
Right, right, right.
00:30:49 - Anthony Campolo
And that's what you get from someone like Rails. Even if you don't understand it, you at least have a thing that works at the end.
00:30:55 - Sean Washington
Yeah. And I've said this in the past too, you know, going from Rails then to Elixir, then to Laravel, and then having to pick up Go for some job interviews.
I was like, where's all the stuff? Where is it all? I'm having to go pick out everything myself. And I have a week to build this project and then go and defend it against basically a board of people. Right.
And I spent a good part of my time vetting things that I wanted to use in the project, because that was definitely a question that was going to come up: Why did you pick this? Why didn't you pick this other thing? You know, I didn't want to be like, because I didn't know it existed, right? I wanted to make it feel like I not only knew the language, but I knew the ecosystem because I think that's pretty important as well.
00:31:41 - Anthony Campolo
Yeah. And that's something that I run into, like just going out and explaining this thing. The first question I get is, why should I use this over Gatsby or Next? That's the first question you get almost every single time, you know.
And it's great. It's an important question to ask and it's a question people should ask. And it's not very easy to answer until you've really built something with each of these tools.
00:32:03 - Sean Washington
So why should people use it over Gatsby or Next?
00:32:07 - Anthony Campolo
Bam! You need a database. There you go. So it's a pretty easy kind of decision tree. The way I think of it, do you need a back end? You know.
And for kind of like newer developers who just fire up a Create React App, they don't even necessarily realize what a back end is or like what it means to not have one, because we've made this whole front end Jamstack deployment so nice that you can get a website up very, very simply. But to get a website up with a database that users can log into and do anything useful with, that's like so many layers removed from that.
So that's why I say if you want to have something, you want to have an application, not a website. If you have an application that has users that do stuff, then you would want to use Redwood instead of Gatsby or Next.
00:32:55 - Rockwell Schrock
So you've kind of been skirting around this, but I just wanted to sort of clarify. When you're designing a framework, you've seen the development process and sort of decisions that have been made to develop the framework for, you said you've been on the team for like six months or so, right?
So what are the core, like Rails, for example, has a bunch of core tenets that sort of drive the design decisions behind Rails. Don't repeat yourself. Developer happiness. Stuff like that. Right. These little mantras. And so are there sort of those kind of guiding principles? From what you just described, it sounds like getting someone to ship something, period, like that seems like a kind of a core thing. Are there other kind of things like that that are sort of core guiding principles of the framework?
00:33:48 - Anthony Campolo
Yeah. We actually do have a specific list of like seven principles on the main website. I forget exactly what they are because I haven't read them in a while.
00:33:57 - Rockwell Schrock
Hold on. I'll pull them up. I'm pulling them up.
00:33:59 - Anthony Campolo
The ones that are important are essentially convention over configuration and just like the fact that it is an opinionated framework in the first place. And then the other ones are going for relational over NoSQL, that's actually in there as one of the principles, and being serverless by default. So essentially always starting from a serverless mindset and only branching out from that when you need to.
And those to me are the ones that really stick out, along with having a single consistent monorepo type thing. I forget what the other three or four are. I think testing is one of them. And yeah.
00:34:40 - Rockwell Schrock
Oh, there's a whole section of docs here that says the Redwood philosophy. It's shame on me for not reading the docs. Put a link in the show notes.
00:34:47 - Anthony Campolo
It'll take you a while. It'll take you probably a month to read the whole docs at this point. They're pretty thorough, but they're well written and they've got personality, which I enjoy.
00:34:56 - Sean Washington
That's one of the things that really stuck out to me. First, because I had looked at Redwood a little bit before you even DM'd me on Twitter.
One of the things — and I don't know, this obviously doesn't necessarily make this true — but when I'm looking at a tool or a framework or whatever, first impressions to me mean a lot.
And when I look at the design and how complete the documentation is, those two things usually say to me there's more quality beneath the surface here.
00:35:28 - Anthony Campolo
This is one of the things I really love about Redwood is that it's a very writing heavy community, and this goes back to Tom's influence.
So I said how Tom had created GitHub and had been an old school Rails developer. But Tom is also known for being the creator of Jekyll, which is kind of like the OG static site generator that a lot of this Jamstack stuff is based on. And he launched that with a blog post called Blogging Like a Hacker.
The whole point of Blogging Like a Hacker is he was saying, my blog should just be in a git repo, and I should just be able to use that git repo to deploy my website. So he created Jekyll, and then he created GitHub Pages. And then that's kind of what we think of now as like a modern Jamstack kind of site.
And then he also coined the term README-driven development. The idea being that you start by writing your readme and then you write the code to make the readme true.
00:36:21 - Anthony Campolo
It's this idea of putting language first. And I feel like that humanizes it because we're working with computers and computers are so abstract and we're trying to talk to the computers, but we're also people talking to each other, trying to use these things. The human element of it and how we communicate about it and the words we use to describe it, it's all so important and it's something that for a long time was kind of seen as secondary.
And I think people like Tom have done a lot of work over a decade to make this idea of putting the docs in a very important place. You can't skip that. And that's why Redwood's cool, because it's taking it a little further into the tutorial, not just the docs. They're saying, okay, now we got great docs, now we need a great tutorial. So we don't just have all the resources there so we can go read and find.
00:37:13 - Anthony Campolo
We have a sequence that walks you through the framework in a way that progressively reveals it to you.
00:37:20 - Sean Washington
It definitely comes across to me like I looked at it and I was like, this thing looks really mature. Oh, wait, it's not even 1.0 yet.
So my first impressions are really, really high on it, I guess. So, yeah, I don't know. I'm definitely gonna have to kick off a Redwood app after this call.
I wanted to also ask about, like, I noticed there was a forum and I did click around the forum a bit, and it seems like there are some Redwood apps in production.
Have you deployed anything in production? Do you know anyone that's using Redwood in production right now? What's that story been like? Sort of beyond just building the thing, maintaining it, right? Because that's the other half of this story — maintaining it and keeping it going.
00:38:06 - Anthony Campolo
Yeah, 100%. For me, if you go through the tutorial, at the end you have deployed an application in the sense that there's a thing online and anyone can go hit that URL and get to the thing.
So you deploy an application, but I wouldn't necessarily say it's a thing that can scale and have a thousand users. That's kind of a different question.
So I haven't scaled an application on Redwood yet, but I do know people who have, and I know many people who are building companies on it right now.
Going back to my friend Chris that I host the podcast with, he is building Ever Fund, which is a UK company that's built around a specific British tax law. And they create donation links. And so it's a real thing that has money running through. He's hooked it up to Stripe. He's also the one who has the Next front end as well.
00:39:03 - Anthony Campolo
And then you have Danny who has Tapesh, which is both a CLI tool and also a screen capture kind of tool. And then there's Repeater.dev, which is another one that's for background job processing type stuff. And then there's a handful of others that I'm not as close to.
But at this point, I think there's close to a dozen Redwood apps in production.
00:39:27 - Sean Washington
That's cool. I mean, that's good to hear. I mean, I wouldn't expect there to be a ton, but it's cool to hear that people are using it.
And also people are being creative, like you said, using headless Redwood, using the back end infrastructure, the integration — sort of isolating your API layer.
So you mentioned like there's obviously the Redwood DB using Prisma. Then there's the GraphQL layer. And then there's affordances for servers or services for working with third party APIs. That's a good chunk of work in and of itself if you're building this thing from scratch.
So even for me, it's really interesting to think about in terms of, okay, if I want to build a thing and I want to use something like Next that I might be familiar with, but then I'm starting to think about the API — instead of reaching for Rails or something outside of the JS ecosystem, because then I have to refresh myself on Ruby, and it's just two languages, there's context switching.
I might be able to or might be more likely to keep things inside of the JS ecosystem or TypeScript ecosystem.
00:40:25 - Anthony Campolo
Yeah, 100%. And that's why I found that it'd be really interesting to have a conversation with you guys coming from more of this back end framework kind of perspective, because this really is something that is very forward facing in how it's using all this React type stuff, but it's wanting to give you a really powerful API that can do the kind of stuff you would expect to be able to do with a Rails back end.
So it's interesting how it splits the difference between those two worlds. I find it brings a strange combination of developers to it.
00:41:00 - Sean Washington
Do you think the real power there comes from the GraphQL stuff? Because with GraphQL you can use it sort of as a gateway, right, with having your service layer there, and your GraphQL exposes it as a single interface. So at that point, your front end doesn't know where any data is coming from, right?
00:41:15 - Anthony Campolo
Hundred percent. And this is why when I say the core part of Redwood is not React, it is GraphQL. I could imagine Redwood envisioned with a Vue front end instead of a React front end.
But if you take GraphQL out, it's no longer Redwood. It becomes a different thing. And this is why I find AWS AppSync to be really interesting, because AWS AppSync is their managed GraphQL API.
And so when I see AWS AppSync hooked up to a DynamoDB database with Lambda functions, that is what a Redwood app looks like.
00:41:52 - Sean Washington
I only know what half of those things are.
00:41:53 - Rockwell Schrock
So the concept of trying to manage that terrifies me. Same with Lambda functions alone.
00:42:01 - Anthony Campolo
Which is why you'd want to use Redwood. You wouldn't want to do that yourself in the first place. And that's why we built Redwood, so you don't have to do that.
00:42:09 - Rockwell Schrock
Would you say that people are, you mentioned some people starting businesses on it. Is it the primary drive there? Like, is it going to be cheaper? Is it just the scaling issue? Is it the infrastructure? Like, you just don't have enough people to manage that?
What is the main reason that a business would choose Redwood?
00:42:29 - Anthony Campolo
I mean, yes, everything you said. Yes to all of them.
00:42:31 - Rockwell Schrock
Okay.
00:42:34 - Anthony Campolo
So yeah, it's really about developer velocity. It's about strong, battle-tested tech. It's about using scalable by default serverless infrastructure. It's about all of those things all together combined to hopefully better, faster, and cheaper. That's something that you're never supposed to be able to get in business. And that's because you have to work for it.
So the rub is you have to rewire your brain to figure out how to create apps like this.
00:43:01 - Sean Washington
Yeah, I mean, there's lots of validation there already. So it's not like this serverless Lambda function, scalable by default approach needs to be validated. You even have things like Laravel releasing Vapor, which is Laravel-ized, I guess — I don't know what to call it — but it's like serverless Laravel.
And I've seen blog posts, like, I keep talking about the analytics company that I can never remember the name of.
00:43:26 - Anthony Campolo
Fathom.
00:43:27 - Sean Washington
Fathom. That's the one. Yeah. Like, they had a Go app, they rewrote it with Laravel and they used serverless. And that allowed them to just keep growing without having to worry about scaling their servers, and without worrying about their server costs just skyrocketing.
I'll have to link the blog post they wrote in the show notes, but I thought that was really interesting to look at.
Of course, you have to build your Laravel app a little bit differently or there's different considerations to make. But the tradeoff is huge, I think. Or like the win in that tradeoff is huge.
00:44:01 - Anthony Campolo
Yeah. And this is something that Brandon, going back to Blitz. They're kind of seen as like the Redwood competitor. Blitz was created by Brandon Bayer, and I've had him on my podcast a couple times, and he has talked about Laravel Vapor and to him, that's what he's aiming for. That's what he sees as like what he wants Blitz to be.
So yeah, you're totally on the money with that comparison.
00:44:24 - Sean Washington
So yeah. And when I think about Blitz, you're saying that it's more like Laravel Vapor. To me that feels more like home. I guess to me, Redwood is like this. I look at it, I'm like, what is this? This is interesting. This looks really cool.
But when I think about Laravel Vapor or Blitz being, to me that's home. But that's just because of my past experience. So Redwood is very interesting to me because it's different enough that it kind of pulls me out of like, this is my home, my safe space. But it's still, like you said, focused on developer experience, focused on a person just shipping something. To me, that's really, really compelling.
00:45:01 - Anthony Campolo
I think this is a good reflection of how I keep saying you and I are coming from this from different ends. I'm coming from the front end, you're coming at it from the back end. And that's why Blitz is more appealing to you. But Redwood made more sense to me initially, and it's that same kind of thing.
Because Redwood is very much still about creating this kind of front end, Jamstack kind of thing. And that's why Redwood is called a full stack Jamstack framework, whereas Blitz calls itself a full stack React framework. Blitz has never used the Jamstack terminology to refer to them. So there's slightly different language being used around each framework.
But those are actually reflective of very real important architectural differences between the two of them.
00:45:45 - Sean Washington
Sure. Yeah. Yeah. With the full stack React portion being it's like a server that lives out there versus the Redwood sort of, you're on the edge, you're distributed in the CDN, you're all over the place globally, I guess you could say.
00:46:01 - Anthony Campolo
Yeah. And that's why I think Redwood is better positioned for this kind of serverless-by-default mentality, whereas Blitz is better positioned for still having a monolithic server running somewhere, which still has its advantages.
Because what's funny is that's what people are doing with Redwood. Even though Redwood is architected for serverless stuff, people like my buddy Chris are running it on a server. They have rewired Redwood to make it serverful instead of serverless, because Redwood is aiming for where the puck is going to be. We're aiming for where serverless technologies are going to be in a year or two.
So right now they don't quite cut it. So that's why people are spinning up their own bespoke PM2 instances running Redwood apps.
00:46:44 - Sean Washington
Oh man.
00:46:46 - Rockwell Schrock
That's great. That was going to be one of my questions. But you beat me to it.
I mean, that makes sense from a, I mean, to get up and running in development mode, all the tools are more or less free. Heroku databases are free. DigitalOcean Postgres hosted databases are basically free, right? And then CDNs are extremely cheap as well. So it's very easy to get started on this.
So I don't think necessarily cost is really an issue for getting up and running. You don't need to use a server just to save money. In fact, it might actually end up costing you more if you start getting traffic, right.
00:47:18 - Anthony Campolo
So the rub is not cost. The rub is your serverless functions can only be a certain size. If your serverless function has too much code, it can't run in a Lambda. There's a certain limitation to how large your functions can be.
So that's where the limitations are hitting. They're not necessarily hitting cost limitations so much as they hit the bounds of what these services were made to do in the first place, because we're rewiring them to do crazy stuff that no one really expected us to do with these things. A Lambda is supposed to be a small function that can be invoked quickly. It's not supposed to be a monolith shoved into a single Lambda.
And that's what we're doing. So that's kind of the problem, is that we're not really using the technology the way it was intended to be used in the first place. So it makes sense why it's not really quite working yet. And that's why we're thinking about maybe creating some sort of hosting provider that hosts giant Lambda functions.
00:48:19 - Rockwell Schrock
Well, it's interesting to think about because you mentioned obviously it's GraphQL on the server. So that means that any Lambda function, like at the bare minimum, has to be able to parse and validate GraphQL, like every single function, right?
00:48:32 - Anthony Campolo
The handler is one giant GraphQL handler. So I was talking about how you have your back end. You have your schema, your functions, your Prisma database, all that gets imported into one file that stitches it all together into one giant Lambda handler. So yeah, you have one giant GraphQL handler in the end. So that's why I say it is literally a Lambda.
00:48:53 - Rockwell Schrock
You got any other questions, Sean?
00:48:56 - Sean Washington
I think I would have to actually try it out. We could probably do a round two, have them back, and then I'll have my list of grievances. Yes.
00:49:09 - Anthony Campolo
Yeah. That's great. You really got to sit down and just build something out with it. And I'm glad you watched the talk that I sent you because I really make a point in all my talks to do a demo where I start from complete zero, I generate a blank Redwood app, and then I just build it out and deploy it and show the entire process. And you can do it — it's like the whole Rails thing. You do it in like 15 minutes, so it has a nice effect.
00:49:35 - Rockwell Schrock
Oh, I had a quick question about that, actually. One technical thing. What's the difference between a component and a cell? What is the concept of a cell in the front end part?
00:49:44 - Anthony Campolo
Yes. So a cell is a concept introduced by Redwood. It's not a super new idea so much as it's a convention for something people were already doing, in the sense that it's specifically a component for data fetching.
So it's not just a component that displays a card or something, it's the component that's actually hitting an API and pulling data out of it. And it's a way to declaratively order your data in the different states it can be in, basically whether it's empty, whether it's loading, whether you get an error, or whether it's a success.
A lot of people do this themselves. They write a whole bunch of conditional logic. If I get this, I'm going to get an error, and if I get the error, I'm going to do this. And if I get this and it works, I'm going to do this.
And so a cell is just a nice way to do all that for you. So you write a single GraphQL query at the top, and then you write what you want to do in the success state. And then all the other states are just handled for you. And so that's a cell specifically for data fetching.
And so this has lots and lots of interesting implications for React server components.
00:50:50 - Sean Washington
So it sounds a little bit similar to React Query or something like that where you define your query hooks and you have sort of a unified API, is loading, is error, data, whatever.
00:51:00 - Anthony Campolo
Right. We're using Apollo instead of React Query, but it's the same thing. You have a client that's doing some sort of GraphQL query.
And then Thomas asked about TypeScript. The second most common question I get after what is the difference between this and Gatsby and Next is, but can I use TypeScript? So yes.
00:51:19 - Rockwell Schrock
Thomas works for Microsoft, so he's legally obligated to ask that question.
00:51:23 - Anthony Campolo
Yeah, we actually have someone who's worked at Microsoft who wrote our types for us, so you should be happy to hear that.
So yeah, the TypeScript thing is, the whole framework has slowly been converted over to TypeScript. It's been a long and arduous process. So I hope you people are happy. But we're getting there.
00:51:47 - Sean Washington
Are you happy, Thomas?
00:51:48 - Rockwell Schrock
Thomas is never gonna be happy. Come on.
00:51:51 - Sean Washington
Yes. Yesterday I jumped to a definition on something, and I was trying to figure out what the types were. And when I got there, it said to make the types. And it was basically just any. That was a little disappointing. It has nothing to do with Redwood, though.
00:52:10 - Anthony Campolo
This is an interesting question. Someone's never asked me before. Can I also get it in Dart/Flutter flavors?
So I was talking originally about how it's going to be multi-client, and essentially it'll be able to have a React Native side that can talk to it. So I would imagine you could have some sort of Flutter side that can talk to it as well, but that's going to be significantly harder to integrate than React Native — a whole different language and toolchain — and I would not be very optimistic about getting it to work particularly well with Flutter beyond a rudimentary, hacky kind of way. It's going to be much, much more optimized for React Native than for Flutter, unfortunately for people who like Flutter.
00:52:55 - Rockwell Schrock
I'd love to see an Electron client as well. That would be cool.
00:52:59 - Anthony Campolo
Yeah, that would be much easier than Flutter. So the other idea is that you'd also be able to do a desktop app as well. Any kind of client that's written in JavaScript should work well with it in the end.
00:53:12 - Rockwell Schrock
So Paul's asking, are you aware of anyone doing React Native with it as yet? And is that, I imagine, as a follow-up kind of question, is that going to be initially what the mobile targets are going to be?
00:53:24 - Anthony Campolo
Yeah. So just because it's already built so heavily around React and the whole React ecosystem, I just couldn't imagine us going any direction but React Native at this point.
I don't know of anyone who's done it. I have to imagine someone, somewhere has done it, but they haven't blogged about it, unfortunately. So this was a tree falls in the woods and doesn't make a sound kind of thing.
So it's certainly not something that the team has put resources into yet. It's something that we're optimizing for in the long run. But it's just like, at this point, yeah. If you want to do it, that would be awesome. I'd be super interested to hear how it goes.
00:54:01 - Rockwell Schrock
Yeah. Paul blogs, he's going to write about it. He'll have it done in a couple of days. Don't worry about it.
00:54:06 - Sean Washington
Yeah, that's pretty realistic. Is it always going to be React? Do you see in the future any sort of Vue support or Svelte support or whatever else support on the website?
00:54:17 - Anthony Campolo
What I imagine is people will build a version of this in Vue. I think someone is going to take Nuxt and slap an ORM on the back, and that's going to be essentially the same thing.
I just don't really see how creating a version of Redwood that integrates with a different front end could lead to any benefits, because introducing Vue is going to break so many other things because of how tightly coupled everything is to your front end framework. And that's why it's really hard to get any of this stuff to work.
And that's why you have this whole micro front-end movement, because everyone wants to write their own front end frameworks, and no one has any idea how to get them to work together. So you just deploy a million front ends in your application. Call it a day, you know.
00:55:00 - Rockwell Schrock
Wait, that's a thing.
00:55:02 - Anthony Campolo
Yeah. I've heard of micro front ends. Yes. Microservices for front ends because of course.
00:55:08 - Rockwell Schrock
I feel worse now that I know this.
00:55:10 - Sean Washington
Is it LinkedIn doing that? I'm pretty sure LinkedIn does that. I read a blog post about LinkedIn doing that.
00:55:15 - Anthony Campolo
I mean, any company that scales to that level, like LinkedIn, is one of the few companies that would actually have a legitimate technical reason to have micro-frontends. I would guess so. Good for them, I guess.
00:55:27 - Sean Washington
But I think the decision to really, again, with the idea of focusing on DX, that decision to hone in on React and make the bindings really tight makes a lot of sense.
00:55:36 - Anthony Campolo
Yeah. It's just kind of how it has to be at this point where all these tools are and getting something that has this nice, tightly full stack, integrated experience.
You just can't do it for both React and Vue at the same time without building two entirely separate frameworks.
I'd be very curious to see what's going to happen with WebAssembly. Down the road, someone might be able to figure out some way to get all this stuff to just compile down to WebAssembly, and then we can all live in a utopia.
00:56:06 - Sean Washington
Sure. I mean, again, someone could also just use Redwood headless and plug it into whatever framework they want to use.
00:56:13 - Anthony Campolo
Yeah, yeah, that'd probably be the most reasonable thing to do at this point. I would just kind of question why. I guess it would just be someone wanting to use whatever tool is comfortable to them.
But I think if you're comfortable with Vue, then you're not going to be comfortable with a Redwood back end either. So it's an interesting question. I'd be very curious to hear, as people who start to discover Redwood who are from kind of the Vue worlds, what the reaction is to it.
00:56:38 - Sean Washington
That's me.
00:56:39 - Anthony Campolo
Yeah. No. It's great.
00:56:41 - Sean Washington
I've only, like, a few months back into React, and before that I'd only shipped one React project. I have many years of Vue experience, though.
00:56:50 - Anthony Campolo
Cool. Yeah, that'll be curious to hear. Kind of as you get deeper into Redwood, like where the hang ups are in terms of the React stuff, because I came at it from like I only had learned React, you know?
So for me, it was a very natural progression because I didn't have to learn React stuff. I was able to just focus on learning the GraphQL and the Prisma stuff.
00:57:11 - Sean Washington
Yeah, yeah. Before coming into this React stuff, the app I was working on was an Elixir-powered GraphQL API and a Next.js front end.
00:57:20 - Anthony Campolo
Okay, so it sounds like you already built Redwood in Vue then a while ago.
00:57:26 - Sean Washington
Right. Right, right. Yeah, it's a lot of work. Let me tell you about it.
00:57:30 - Anthony Campolo
I keep saying all these people, everyone's building Redwood before Redwood.
00:57:34 - Sean Washington
Yeah. I'm really interested to give it a try, though. You definitely, there's been some people in the chat saying, like, well, you made a sale, so.
00:57:43 - Anthony Campolo
Yeah. And it's like, you know, for me, I'm just someone who got so much value from the framework, not only from what I could build, but from the mental model it gave me and the ability to converse on these kind of bigger idea topics and have a shared vocabulary with a Rails developer or Laravel developer and be able to speak a language that makes sense to both of us.
And that's what I really got out of it more than anything. And so this is a popular refrain from Rich Harris, the creator of Svelte, that I really love, is that frameworks are not tools for applications. They are tools for your mind.
00:58:23 - Rockwell Schrock
And I always like the lack of infrastructure you have to maintain. I'd be much more likely to sort of do a hobby project that way if it was easy. Right?
Because I'd be able to just spin it up and it would cost me nothing and I would never have to worry about updates or keeping it. You know, the only thing I really have to worry about is the database. But if it's a hobby project, like who cares, right? Just throw on some backups and you're fine.
Everything else is basically disposable, and I can just let it run forever, until I die. So that is definitely appealing. Because sometimes there's some friction there. It's like, do I even want to start this thing if I know that I'm going to have to just maintain it forever?
00:59:02 - Anthony Campolo
Yeah, it's definitely the no DevOps kind of mentality. This goes back to the kind of serverless by default stuff. Serverless by default is really just saying I don't want to do ops.
00:59:14 - Rockwell Schrock
Yeah, exactly. Well, before we wrap this up, do you have any other shout outs, things you're doing, working on? You mentioned the podcast. You mentioned Redwood once or twice, I think. Any other stuff you got going on?
00:59:28 - Anthony Campolo
I have a blog. So my general handle is AJCWebDev. And so if you go to twitter.com/AJCWebDev, you'll find my Twitter. Same for GitHub or dev.to. So that's kind of the main areas that I congregate.
I do lots of talks. I do talks about other things as well. I've done a Nuxt talk. I just did an AppSync talk yesterday. I've done a Deno talk. So Redwood is kind of my bread and butter right now, but there's definitely a lot of other technologies that I'm interested in that I'm slowly starting to get my feet wet with.
So yeah. And feel free to just message me if you have any questions about any of this stuff. I'm in the DNC Discord as well now. And, you know, we're all getting along really well. I am friends with you guys now and I know you all so well.
01:00:18 - Anthony Campolo
I literally murdered a bunch of your friends last night.
01:00:21 - Sean Washington
Yes. You were very efficient with the knife or gun or tooth spike or whatever it was.
01:00:29 - Anthony Campolo
Yeah, that's pretty much it.
01:00:31 - Sean Washington
Well, thanks for coming on the show. We're glad that, you know, you're around in the community. Like you said, we'll be talking a lot more in the future.
And I'll definitely be checking out the podcast, and we'd love to have you back sometime to just kind of follow up on our experiences, because it sounds like a couple of people, at least in our community, are going to try kicking around ideas. We're always making new stuff. So it sounds like a few people are wanting to give Redwood a try. So we'd love to chat about it more in depth when we have actual real world experience.
01:01:00 - Anthony Campolo
Yeah, happy to hear. I'm happy to come back anytime. And yes, you can sponsor me on GitHub. Thank you, Thomas.
01:01:06 - Sean Washington
Well, we'll make sure to put that link first in the show notes. If anybody else has any feedback or questions or thoughts on Redwood or anything we talked about today, you should definitely check out the show notes at DNC. All the links that we talked about are there, the article, every video. We're going to put it out there on Twitter.
01:01:25 - Rockwell Schrock
You can reach us. Anthony is AJCWebDev. Wow. Got it right the first try.
The show is DNC Cast. Sean is Sroquel. You can join us on Twitch every Thursday night at six Pacific, nine Eastern, twitch.tv/DNCCast. Next week we have another guest. Mystery guest. You can probably guess who it is because we talk about it on stream. But next week, come join us in the chat and see our guest.
01:02:06 - Sean Washington
We also have a community Discord, as we've talked about at least a few times tonight. And if you're interested in talking shop, talking web dev, talking music, cooking, stocks, money, whatever, we just talk about life and we just want to learn and we want to help each other learn.
So if that sounds interesting to you, check out the show notes. We'll have a link to our Discord and we'd love to have you.