We’re talking about RedwoodJS. What exactly does it mean to be a full-stack Jamstack framework? I spoke to community champion Anthony Campolo to find out.

Show Notes

• RedwoodJS
• Anthony on Twitter
• Anthony’s article series A First Look at RedwoodJS

Weekly Update

• “An Introduction To Running Lighthouse Programmatically”
  written by Katy Bowman
• “Animating React Components With GreenSock”
  written by Blessing Krofegha
• “Designing For Attention”
  written by Victor Yocco
• “Advanced GraphQL Usage In Gatsby Websites”
  written by Aleem Isiaka
• “Comparing Styling Methods In Next.js”
  written by Adebiyi Adedotun

Transcript

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

Drew: Hi, Anthony. How are you?

Anthony Campolo: Hello. I am smashing, thank you so much for having me.

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

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

Drew: So, it’s a full stack framework that tries to put together a lot of the ideas around a Jamstack development ecosystem? Is that right?

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

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

Anthony: They’re seasoned. Yes, I’ve actually put a decent amount of time into writing about the history of the framework and the ideas that have led to it, and Tom Preston-Werner is the creator, and so he’s also known as the creator of Jekyll, which is a really influential static site generator. He also did TOML, the configuration file language. And he was the CEO of GitHub originally. So, his work with Jekyll and GitHub pages and that sort of thing I think has really led to what we now think of as the Jamstack. A lot of people would say, "Oh, the Jamstack’s new. They’ve been doing this forever." That’s how we’ve been talking about how it’s an extension of these older ideas, the static site generations, but with GraphQL and serverless and these ideas of how to use glue code and APIs to make your app work.

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

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

Drew: Okay, so starting at the front, as you mention, it’s based around React. Is that React plus a bunch of Redwood code, or is it just plain React? What’s the balance there?

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

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

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

Drew: I think it’s a common pain point that you hear from lots of people when they’re trying to get started in the modern development framework with client side JavaScript apps and configuring web pack, configuring all the different things, the build processes, the build steps. It can be quite a minefield, can't it, to get everything hooked together and working? And it’s a long way before you get to "Hello, World!". So, Redwood is giving us all that preconfigured?

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

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

Anthony: Yeah, the router is, it’s very sophisticated. It does most of the stuff that you would get just from React router, it has just kind of different ideas in terms of how these should be implemented, because Next they also have their own router, and it’s still not really entirely figured out how we want to get our single page app routing to work. Because of Suspense, you have a lot of these kind of questions over where is the async stuff going to come in? We have with Redwood, this idea of a cell, and this is what really does your data fetching for you.

Drew: So, maybe we could go into that a little bit? What is a cell in terms of Redwood?

Anthony: Yeah, so a cell is a default way to write a GraphQL query and then have your page basically tell whether you’re getting the data back, whether you’re getting an error back, whether you’re in a loading state, or whether... There’s one more state, I forget. But yeah, so it gives you the different states that basically you can be in based on whether you are getting your data or not. It’s setup with Apollo under the covers. So, if you’re using Redwood, you’re using Apollo as your GraphQL client, but you don't ever have to think about it. You never have to write any Apollo or even think about it, it’s all baked in. It lets you just write GraphQL queries, which was really the dream of why people wanted GraphQL, is that it was this really simple query language that front end devs could use. But then, you had to figure out how to set up a GraphQL server, you had to figure out all this other stuff, and how do you get that all wired up. So, it does all of the GraphQL integration for you so you can just write GraphQL, you don't have to think about how do I even implement GraphQL.

Drew: So, I guess one of the classic jobs of a framework is to take all the boiler plate code that you could write yourself and implement it for you, and tidy the way behind the scenes so you never have to look at that boiler plate ever again, and you can just write the code that’s unique to your circumstance. I guess that’s what’s going on with a cell is it? There’s nothing revolutionary here, it’s something that you could set up a React component to have all this different states and you could hook in Apollo and you could do all this yourself, but that’s actually quite a lot of work and it’s a common pattern. So, Redwood has tidied up into a nice, reusable pattern that you can just start using without having to think about it. Is that a good description?

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

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

Anthony: Yeah, and I think it’s really interesting that we’ve seen multiple different attempts at this solution to this problem, because I mean you’ve had people who’ve been saying it forever, "Why isn't there a Rails for JavaScript or a Rails for React?" There’s a great Full Stack Radio interview between Michael Chan and Adam Wathan called React is Not a Rails competitor. This is one of the different frameworks.

Anthony: The other ones are BlitzJS which has gotten a decent amount of buzz, and then Bison is kind of a new up and coming one. They all have a similar stack, but they use different pieces. You’ll have React query instead of Apollo, or you’ll have Chakra instead of Tailwind. The people who are putting together all these pieces into their stacks, all these stacks are kind of, they’re battling it out, it’s all very friendly competition. Actually, that’s one thing that I really appreciate, is that we actually all collaborate between the frameworks as well. There’s no animosity there.

Drew: So, we’ve mentioned Apollo and GraphQL, Redwood uses GraphQL quite heavily as one of the core pieces, isn't it, of the framework? We can probably dedicate an entire podcast episode to just GraphQL, but for those who aren't familiar, what piece is GraphQL doing here, what problem is it solving in this context?

Anthony: Yeah, this is a great question. When I am telling people what they should know to have a good start with Redwood, I’d say that you should have used Create React app, just if you’ve made a Create React app, and you’ve deployed it to Netlify or Vercel, that’ll get you a good start. Then, know at least a little bit of GraphQL because it is very central. So, the GraphQL is how your front end will talk to your back end. They say it’s a query language for APIs, the idea being that it’s meant to be an alternative to RESTful API methods, and that instead of doing that RESTful thing, you are sending queries which specify exactly the hierarchical data structure you want to receive back from the database. So, it requires a little more startup time to get your GraphQL server to talk to the two pieces. Then, once you have it there, the front end developers have the ability to get data in much more flexible way. You don't need all these different API endpoints that your back end guys need to keep making.

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

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

Drew: So, we’ve got GraphQL there giving us the ability to query some sort of back end. In Redwood, what is the back end?

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

Anthony: I actually built a just proof of concept app where we used FaunaDB instead. FaunaDB, they have their own GraphQL API, so you can just send GraphQL API straight to Fauna, and then do your database mutations that way. You lose a lot of the functionality of Prisma’s CLI, but Prisma really it’s a convenience factor to work really easily with your relational database. But really, anything you could think of, you could figure out how to hook it up with Redwood is what I found out just because it’s built around GraphQL and the whole point is to be able to talk to all these different pieces.

Drew: So, Prisma is essentially a sort of abstraction layer between your code and whatever data store that you’re using presumably that Prisma supports, is that... or is it doing more intelligent things than that?

Anthony: Yeah, so you write a schema, so you create a schema.Prisma file, and it would have model post, and then it would have id and integer and auto increment, like title sting, body string, created at date, time. So, you’d create basically what you want to be in your database with the types, and then it does the database stuff for you so you don't have to interact with the database.

Drew: So, you use Prisma to define I guess what sort of database or what sort of data store that you’re talking to. Then, in there you lay out your different mvc models to use that parlance. So then, when your application is talking to the data stores, it’s kind of using an instance of a Prisma client, is it? Is that what’s going on?

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

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

Anthony: That’s exactly how the tutorial is set up, that’s the workflow it shows you.

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

Anthony: Yeah, no, that’s such a good point, because I say that for all the new stuff Redwood combines together, there’s some things that actually says the old, tried and true way is actually the best. So, they are really big on relational databases. That comes from Tom’s experience with using Rails and having a relational back end. Active Record was the O/RM layer that Prisma’s meant to approximate.

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

Anthony: Yeah, so in the back end, there’s a file specifically that is a way to take your SDL, so you have your schema definition language, and then you have what are called your services, which are like your methods for talking to your back end. Then, all of this gets stitched together into a GraphQL handler that is deployed to a single Lambda function. So, it’s optimized for Lambda specifically. We actually just recently had someone do it with the serverless framework, and we’ve got some people working on Azure and Google Cloud something. It’s not Google Cloud function, it’s the one built on top of that. But yeah, so it’s right now basically optimized for deploying your back end as a GraphQL function in an AWS Lambda. This is the stuff that’s all magic happening in the code I don't understand, but that’s the high level explanation.

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

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

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

Anthony: Yes, that’s where Heroku comes in. So, in the very last part of the tutorial, you deploy your front end to Netlify and then you deploy your back end to Heroku Postgres and you just grab your config variables from Heroku, plug it into Netlify. Getting your Netlify front end to talk to your Postgres back end is a really, really simple thing. They wanted to go with the thing that was going to be the easiest for anyone to get spun up, but still have good stable, battle tested tech. At the end, what you get out of the box just by following the instructions, is really incredible.

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

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

Drew: So, because Prisma understands your model and it knows how to query them, is it able to generate some kind of migrations or things like that to help you get that database set up?

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

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

Anthony: This is probably the biggest key feature that you get from Redwood, is you get a whole set of very sophisticated generators. For anyone who’s ever seen the original Ruby on Rails demo, that DHH gave, he builds a blog in like 15 minutes and he does it all with Rails, and people are like, "Whoa, this is amazing." That’s the effect Redwood is going with. They want you to be able to get everything spun up really quickly so you can generate pages, you can generate layouts, you can generate your cells, which I was talking about, and you can do a scaffold command that is going to create your entire CRUD interface. I have a whole section, part four of the blog series, just explains all the code that the scaffold gives you. It gives you so much code. There’s an off generator, there’s even a Tailwind generator that configures your tailwind for you.

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

Drew: If you wanted to just deploy that and have that in production, presumably you can just deploy it along with your front end code, but you’d need some way to secure that aspect, those roots in your application.

Anthony: Yeah, there’s a couple different options for authentication. You can use Netlify identity. That’s the default if you go into the tutorial, and then you can also use Auth0, and then one I’m not familiar with called Magic.Link, and there’ll probably be a couple of extra ones added in the future. But yeah, so there’s a couple built in solutions there already, and that’s the very last thing you do so that’s the very last part of my whole 12 part blog series is the Auth one. I don't think I’d ever figured out Auth before I used Redwood. It’s hard and they’ve definitely done a good job with it.

Drew: Does that integrate at a route level, or a route level, sorry, how do you secure things?

Anthony: Yeah, so part of how they have their own router, they also have... You can do private routes, so they have a private route component. Then, your actual login form, that’s what you get from Netlify identity so you don't have to actually create a form and do your state management with that, that is where a lot of problems come into play. Taking away the really key parts and then you can just implement role based access. We have role based access control add on that was been done over the last couple weeks be David T. So, there’s a lot of work happening to create other ways to do it, but what they got now is already... it works, it’ll get you functional.

Drew: People always say about security algorithm hashing cryptography, that you should never write your own because it’s never going to be as good as the things that are out there. Increasingly, I think that’s also true of authentication at a higher level; that authentication is such a complex area these days that people want to not just log into your site with unique credentials, but they might want to authenticate using Google, or they might want to authenticate using an Apple device, or they might want two factor authentication, or they might want to integrate it with a single sign on service that they’re using from an enterprise. All these things are such a headache if you try and implement it yourself and so much opportunity for getting something wrong and exposing security holes in your application, that using an authentication service seems almost like a no brainer at this point to me. So, just being able to drop something in with essentially a few lines of code and be up and running sounds like a really productive way to work and to keep things secure.

Drew: It sounds like the deploying both the front end and the server aspects, the serverless function things, is a naturally fit for deploying to Netlify. Are you tied into that with Redwood? I mean, we mentioned that Tom Preston-Werner is one of the main proponents of this framework, he’s also on the board at Netlify. Do you think there’s potential for too tight a coupling there if you were to choose Redwood as the basis for a project?

Anthony: Yeah, this is something that Tom’s definitely conscious of. He’s invested in a lot of companies that float around. He invested in Prisma and Fauna. He wants to just make the tools he wants to use. It’s not about we want to lock you into this thing so much as what Netlify has built he thinks is the best option, so that’s why they built around it. But, they don't want it to be locked in to any one deploy target, and that’s why we have work being done on things like the serverless framework and some people have talked about Begin. We want to be pragmatic, we want it to work for whatever someone’s use case is. So, we get you 90% of the way and then you just have to wire up the last couple things to get it to work with whatever your servers of choice is.

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

Anthony: Yeah, there’s a actually a term that Tom talks about as the core philosophical idea behind Redwood, which is that we want to get to a universal deployment machine. That’s kind of t idea, is that you can just deploy things and you don't have to think about it at all. He’s been talking about this idea for years and years and years, and this is what Jekyll was even about back in the day. When you hear that now, you’re like, "Oh, you mean like Netlify?" That’s basically what Netlify is to most people who are working on the front end. They don't even think about deploying anymore, it’s not even a thought.

Drew: Here’s my application in a Git Repo, this directory is the front end, this directory is the back end, here’s my database, and that’s about as much configuration as perhaps you would need for then whatever service to take it and to build it and host it.

Anthony: Yes, and one thing I should also point out, we just very recently got Vercel Redwood default deploy set up, so when you’re deploying on a server side app you can say, "Oh, I have Gatsby app," and it knows exactly how to build a Gatsby app versus a NextApp. We have that for Vercel now. So, there are really, really good non-Netlify options as well, if you’re more into that.

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

Anthony: Yeah, we’ve got about a half dozen apps that are in production right now. The first one was called Predict COVID, which came out back in March, and it’s like a realtime data visualization application. Then, we’ve got repeater.dev is done by Rob, it’s like a cron job like thing for Jamstack. Then, there’s Tape.sh, Duoflag I think is another one. So, there’s at least a handful. If you go awesome Redwood repo, you can see a list of all of them. If you go to the community forums, you can find write ups of these as well, because people have put these into production and kind of said how it went. So far, they’ve all been successful and no one’s said, "I’m never using this again."

Drew: But, it is very new. I guess there’s no escaping that, but in terms of maturity, Redwood’s pretty new, it’s getting a good following.

Anthony: Well, it’s funny, it is and it isn't. It was announced in March. At that point, it had been worked on for about a year by Tom and Peter. So, they’d already put a ton of upfront work into this, so it wasn't like I’m going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't... It’s not a 1.0 now, but it’s pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it’s not ready. So, we say it’s not ready for production even though it’s in production.

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

Anthony: Yeah, it’s a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there’s a version bump, you just do a command and it bumps you up the version. I’ve been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it’s like 0.17 or something now. So, I’ve been slowly iterating on it as it’s gone but nothing breaks. It’s all, you get slowly things, or like "Oh, this is kind of a nice little touch you’ve got here," but it’s pretty much set in stone architecturally. Redwood as it’s structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That’s why they built it, so they could get something that’s structured like this thing.

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

Anthony: That’s exactly why Tom inventing semantic versioning.

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

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it’s called that, is that you can just make a site and deploy it and it’s not going to break, it’s just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that’s huge. Being built by people who tried to scale Rails apps, I imagine they’ve thought a lot about that. But in terms of the going away part, that’s always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom’s a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that’s going on, so I wouldn't worry about that too much-

Drew: Of course.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it’s very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There’s few people with more open source cred than Tom, so he’s done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I’m a boot camp student, I’m learning all this stuff as I go. I’m not pushing code to the repo, I’m making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there’s really a lot of things about how they approach community building that I have a lot of respect for, and that is why I’ve been so invested in it and putting so much of myself into it.

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

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

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

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

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it’s this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking... I’m in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We’re essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it’s all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it’s much more modular than you would think based on... You talk about it, and like you said, it sounds like it’s a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it’s made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it’s going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you’re interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that’s why it’s a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They’ve really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you’re interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I’ve been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I’ve been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you’ve been around the block, you know a lot of CMSs. Obviously, you know you’ve got your WordPress's, your Drupal, but what’s really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it’s just such a natural fit. So, I’m trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I’m not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I’ve not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you’ve got to join the club, dude.

Drew: Yeah, no, I’m definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it’s certainly one of the things that I need to be learning.

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

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

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

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

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