Anthony Campolo joins the conversation to lead the discussion of RedwoodJS. RedwoodJS is a full-stack framework that provides a way of building a fast and secure front-end that JAMstack gives you with the power and flexibility of a backend.

It doesn't have an official ORM, instead it uses GraphQL through Prisma. This discussion goes deep into the history and implementation of RedwoodJS.

Panel

Guest

Sponsors

Links

Picks

Special Guest: Anthony Campolo.

AIMEE_KNIGHT: Hey everybody, welcome to another episode of JavaScript Java. This week we have our panelists. We have Dan Shapir. 

DAN_SHAPPIR: Hi from Tel Aviv, where it's actually winter. 

AIMEE_KNIGHT: We have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo, coming at you live where I don't think it's still winter.

AIMEE_KNIGHT: Steve Edwards. 

STEVE_EDWARDS: Hello from Portland, where it's definitely winter. 

AJ_O’NEAL: It's still snowing. It's winter. Yeah, sorry. Check outside. 

AIMEE_KNIGHT: I am Amy Knight coming at you from Nashville, Tennessee. And our guest today is Anthony Campola. You want to introduce yourself? 

ANTHONY_CAMPOLO: Hello, hello. Come at you from Pleasanton, California. It's sunny, but pretty windy. But it's nice. Thank you for having me. I'm a huge fan. I feel like I'm a guest character on one of my favorite TV shows right now. 

AIMEE_KNIGHT: We're happy to have you. 

 

When I went freelance, I was still only a few years into my development career. My first contract was paid $60 an hour. Due to feedback from my friends, I raised it to $120 an hour on the next contract. And due to the podcast I was involved in the screencasts I had made in the past, I started getting calls from people I'd never even heard of who wanted me to do development work for them because I had done that kind of work or talked about or demonstrated that kind of work in the videos and podcasts that I was making. Within a year, I was able to more than double my freelancing rates and I had more work than I could handle. If you're thinking about freelancing or have a profitable but not busy or fulfilling freelance practice, let me show you how to do it in my DevHeroes Accelerator. DevHeroes aren't just people who devs admire, they're also people who deliver for clients who know, like, and trust them. Let me help you double your income and fill your slowdowns. You can learn more at devheroesaccelerator.com. 

 

AIMEE_KNIGHT: And today we're gonna be talking about RedwoodJS. You wanna give us maybe an intro to yourself and then an intro to what RedwoodJS is? 

ANTHONY_CAMPOLO: Absolutely, I am someone who came from non-traditional background in terms of how I got into coding. I originally was a music teacher and spent a while after that running a performing arts summer camp and got really into like admin work, running events, doing logistics, that kind of stuff, which was great. And I learned a lot, but I kind of wanted to get more into something a little more creative, a little more interesting in terms of like, you know, what you can learn, what you can build. So I eventually found my way to coding and did the Lambda School Bootcamp, which is a remote bootcamp, learned a lot of React and that kind of stuff. And I eventually found my way to this framework, Redwood JS, which is a full stack framework for React. And it's basically a tool to help integrate a lot of the types of things you need to do when you're building like a modern React application today, which I was really struggling with at the time going through the bootcamp and trying to build these applications while also just learning like what code is in the first place. And I found that it really gave me a boost in terms of what I could build with it. But even more than that, like the mental model it gave me. So yeah, that's kind of where I'm at right now. I eventually was asked to join the core team as their kind of like main developer advocate. So I get out and I kind of communicate about the project and talk about it with people such as yourself.

AIMEE_KNIGHT: That is awesome. That's also, I don't know, it's impressive. I love hearing like success stories of people like that. So awesome. I know the first question that comes to mind for me and what we were kind of talking about before this started. So, you know, Next.js I think is kind of like the go-to for React. How does Redwood.js compare to that? 

ANTHONY_CAMPOLO: Yeah, Next is a fantastic framework. And it is good for creating really sophisticated client sides and doing like your routing and giving you nice page-based conventions around like how your components match your pages. So there's a ton of great stuff that Next gives you, but what it really doesn't give you is it doesn't give you any opinion in terms of the database. Now some people will call it a full-stack framework because it has a server side and this is true. It does have a server-side, but it doesn't have something like an ORM say, like it doesn't have something like Ruby on Rails has with active record. That's really the main difference that I like to stress with Redwood is that it has a very strong opinion about how it connects to your database because it uses a tool called Prisma, which we can get into a little bit as we get into this. But yeah, basically it just has like an easy way to actually connect your front end to a backend. So it's a full stack framework as kind of like a Ruby on Rails, not exactly, but it's very much giving you the full front end and back end all contained in your project. 

DAN_SHAPPIR: And I understand that it's definitely in the category of gemstack frameworks. I mean, we mentioned next, there are obviously other gemstack. Gemstack is kind of like everywhere. Maybe it's worthwhile, even before we begin to talk about Redwood specifically, to talk about what gemstack is. And how it's different from things that aren't Jamstack. 

ANTHONY_CAMPOLO: Yeah, I think if people want to know about the Jamstack, one of the best resources is actually an episode you guys did back in 2016 with Matt Billman, CEO of Netlify. He kind of laid out back then what the Jamstack is to him. But for me, what it really is, is it's an evolution of static sites and static site generators. So if you think of Jekyll, and GitHub pages. Jekyll was this really great static site generator that was written in Ruby. And then it integrated really well with GitHub pages. So you could use Jekyll to generate a simple web page and then use GitHub pages to get that site on the internet really, really simply. And the Jamstack was kind of the idea of, okay, we have this really nice deployment paradigm for these static sites and we get a ton of reliability and security and availability from the globally distributed CDNs. But what we don't have is we don't have a backend. We can't, how do we do off? How do we do all the things we need to do with the backend? So Redwood is about how do we take this really nice deployment paradigm we have in our front end Jamstack kind of world and extends that into the entire stack. So that's why we say we're bringing full stack to the Jamstack. 

DAN_SHAPPIR: But what does that actually mean? Does it mean that there's just a whole bunch of standard APIs that are provided in the backend? Do I need to just learn the whole lot of things? It seems that based on your initial description, that it's kind of opinionated, but I'm not exactly sure. You know, what, what the bigger picture is. 

ANTHONY_CAMPOLO: Yeah. Let me kind of break down the, the architecture for you guys. It's, it's not super complicated. It's definitely opinionated and it's definitely giving you a very, it's definitely a convention over configuration kind of idea, but it's still like opinions, strongly held or strong opinions, loosely held kind of ideas. You can change things and move it around, but let's just talk about like the canonical Redwood stack. And then we can talk about how to modify the canonical stack later. So the canonical Redwood stack is you have a front-end react app that is speaking. So first, so first you have a mono repo, you have a mono repo with a web folder and an API folder. Your web folder is basically just your react front end. You can think of it like your create react app or like your next, any of that kind of stuff. So that's your web folder. Your API folder is where you have two things. You have your GraphQL schema and resolvers, and then you have your ORM kind of tool, which is Prisma. So your front end speaks to your backend through GraphQL, and then it speaks to your database through Prisma. So that's kind of like the high level architecture. 

DAN_SHAPPIR: Oh, you're one of your yet another GraphQL poster board. 

ANTHONY_CAMPOLO: Big fan of GraphQL, yes. I don't think GraphQL is the solution to all problems, but I think it is a very, very nice way for the front end and the back end to speak to each other and have just a coherent language for, so that everyone doesn't have to just create their own bespoke JSON APIs. That's really kind of just what I see. GraphQL providing is it's a way for the friend in the backend to talk to each other in a more coherent kind of way. And yeah, so that's, that's kind of what I see. And then there's obviously lots of benefits in terms of, you know, not over-fetching and things like that. You guys have done tons and tons of episodes on GraphQL, but for me, it's actually the, the mental model of how front end developers are able to write. GraphQL is really what, what makes it so appealing to me because it makes it very easy to write queries or even write mutations in a way where your friend developer doesn't have to necessarily know the entire backend and how it works and how to interact with it. You can just give them a simple convention of how do you actually write these queries and mutations to access the backend in a way where you don't have to learn the entire backend to do that. 

DAN_SHAPPIR: Oh, sorry. Go on. 

AIMEE_KNIGHT: I was going to ask too, before we pick up Steam too much, I'm kind of curious, like the origin stories of Redwood JS. I think how long it's been around and who started it and all that good stuff. 

ANTHONY_CAMPOLO: Yeah, actually the history of the project is one of the things that really drew me to it in the first place. And I spent a lot of time blogging about it and kind of drawing out this whole history and like a long multi-part series that I wrote about it. And I'll look into the chat after I finish. The history is Tom Preston Warner was the creator of Jekyll. He was also the first CEO of GitHub. So he's connected to all these kinds of ideas in terms of the static site generators and how this all fits in. So Tom was creating a company called Chatterbug with a friend of his named Peter Pistorius. This was in 2018. So Chatterbug is a language learning platform and it was a React front end speaking GraphQL to a Rails backend because Tom was an old-school Rails developer. He built GitHub with Rails and that was what they were familiar with. But as they were working with all this like React, GraphQL type stuff, they were like, there's a lot of benefits here and this tech is really powerful, but getting it to all work together is just really hard. It like takes a lot of time and a lot of specialized knowledge. And they were just thinking, you know, how could we figure out a nice framework to give us these kind of Ruby on Rails like conventions, but for this modern JavaScript, new paradigm that we're working with. And then in 2019 is when they actually started the project. They started a repo in June of 2019 with a ReadMe, because Tom is known for ReadMe-driven development. He's the one who coined that term. And they were working on it just kind of by themselves, just the two of them, and then for close to a year. And then March, of 2020 is when it really kind of launched and went like public. That was the version 0.1. So we're getting close to about a year from the 0.1 release and we're aiming for V1 within the next couple of months. So kind of like a year, but that's a, that's kind of like that, the history of like where, where we've been, where we are and where we're going. 

AIMEE_KNIGHT: Awesome. Thank you. 

SYEVE: So I have a question real quick. I want to go back to you were talking about the structure of the application. So you said you'll have a web directory for your front end. And then you said you'll have GraphQL. Tell me about the two directories for the backend as well then, again. 

ANTHONY_CAMPOLO: Yeah, absolutely. So your backend, it splits into two folders. There's your DB folder, which is Prisma. That has a Prisma schema. If you've never seen a Prisma schema before, it's basically a way to just define both what database you're using and your models at the same time. So you can say, I want this to connect to a SQLite database or a Postgres database or a MySQL database. It doesn't do no SQL right now, but it's on the roadmap. And then you write a model. So it'd be like model post. Then that post would have an ID title body created at. So that's your kind of DB folder. It's just a Prisma schema. And then your other folder is an SRC folder and it has your GraphQL schema. So your schema will be very similar to your Prisma schema and you'll also have like, you know, type post and it'll have ID, title, body and created app. And then you'll also define your mutations and your queries and all that. If you don't know like what an SDL is with GraphQL, that's kind of something that you learn as you go along with the project. And then you also write your services and your services, you can kind of think of them like backend, like a controller logic a little bit. It's not quite the same, but that's kind of the idea. They're kind of like resolvers. And then you have one, you then import your DB. So you import the Prisma client essentially. And that's what's actually doing the object to relation mapping. And then there's one file that basically stitches all that together and shoves it into one giant GraphQL Lambda handler. So they call this a LambdaLith is what we're doing. We have the entire thing is like one giant monolith shoved into a Lambda, which is like, in some ways a bit of an anti-pattern, but it works. And that's kind of like how the backend is all stitched together. So does that make sense? 

STEVE_EDWARDS: So the front end is only communicating with GraphQL and GraphQL is using the Prisma for the actual communication with your database. Is that correct? 

ANTHONY_CAMPOLO: Yeah, yeah, you got it. 

STEVE_EDWARDS: Okay.

DAN_SHAPPIR: And the GraphQL backend implementation is part of the framework itself. You're not relying on anything like Apollo or something like that. 

ANTHONY_CAMPOLO: Yes and no. The framework is an assemblage of tools, Apollo being one of those. So it does have Apollo client and Apollo server in it, but you never really write Apollo. It's one of those things where because of how the tools are integrated, like you write Redwood, you don't think about any of the tools that that make it up until you hit problems, of course. But the main thing is that it takes things like Apollo and Prisma and integrates them. So you don't have to think about the tools too much. It should just work. 

DAN_SHAPPIR: And in terms of deployment of the backend, what you said is essentially it runs on the AWS platform. It runs as Lambda functions or services. 

ANTHONY_CAMPOLO: Kind of. That's not exactly right. Yeah. So, so what happens is when you deploy it, the way you use the, so if you go through the tutorial, the tutorials, how most people are going to build out a Redwood app, but it's not the only way to do it, but if you follow the tutorial, you deploy your front end to Netlify. So Netlify is what is deploying your front end. And then Netlify is what handles the AWS lambdas kind of for you, because you can have just like a Netlify functions folder that does that. And then your backend is you spin up a Heroku Postgres database. And then you take that environment variable and put it into your Netlify dashboard. So you just have a Netlify frontend connected to a Heroku Postgres backend. And you don't have to think about the AWS stuff. Now, what we want though, is we don't really want that. That's not really what we want. What we want is the whole thing to be deployed in one single area. So if we can get the front end and the functions and the backend, all on AWS, like one dashboard, it's like nice and easy to use. That's kind of the dream and kind of like what we're working on right now. Right now it's kind of like this still somewhat distributed thing where you need to have two dashboards and you need to have your Netlify and your Heroku and integrate those two together. Like the integration is ridiculously simple, but it's still a little bit of manual effort there. 

DAN_SHAPPIR: So essentially you're leveraging the fact that Netlify is kind of becoming the go-to solution for various gemstack offerings of bridging the gap between the cloud service providers and CDNs and the gemstack platform of your choice, right? 

ANTHONY_CAMPOLO: Yeah. And it's worth mentioning here that Tom was an early investor in Netlify. He's actually been involved in Netlify since the very beginning. And he has an idea that he calls the universal deployment machine. And this idea is simply that you should be able to write your code on your computer and it's just text. And then you push that up to a Git repo and that is it. That is the website that goes live. Everything is done. That is the entire deployment process. That is what he is aiming at with the idea of the universal deployment machine. And then getting that to deploy to the world is then the next level. How do you get the universal deployment machine to not just deploy to US East one? 

DAN_SHAPPIR: Now in terms of being gemstack, usually what is associated with that is static site generation and recently also SSR. Some gemstack platforms support it, some don't. What's your attitude towards this? 

ANTHONY_CAMPOLO: Yeah, I think if you're looking for static site generation or SSR, you should be looking at tools like Gatsby or Next. That's really what those are optimized for. And this is why some people are actually taking Next and attaching it to a Redwood backend. So some people are doing what I call a headless Redwood where they don't use the Redwood website. Instead, they just use the Redwood API side. So the backend that I was explaining to Steve, and then they attach any kind of front end they want to it, in this case being a Next.js client, because Next.js gives you really nice SSG and SSR. It has a lot of stuff baked in. They've been optimizing that you know, four years. So that type of stuff is making it into Redwood. There's a lot of work on being done on that from the team, but it's really more aimed at a kind of like data intensive, interactive application. It's much more about this idea of web apps over websites. Uh, this is something that, uh, Sean Wang, Swicks, who some of you may or may not know, he talks a lot about how he says, you know, like Svelte is for sites and React is for apps. And so to me, like Redwood very much encapsulates that idea of using React for apps. 

DAN_SHAPPIR: If I'm just using Redwood, then currently what I probably would build is a backend, which effectively serves an empty webpage, like an empty body type webpage with the whole rendering done with clients that React talking to the back to a backend using a gem stack and using a GraphQL API. And alternatively, if I want to do it with service side rendering or static side generation, then I'm effectively might be using, for now at least, Redwood as a sort of a headless CMS sort of a thing and hooking it up with something like Next.js. 

ANTHONY_CAMPOLO: Yeah, it's kind of a question of like what exactly you need to build and how sophisticated it needs to be because you wouldn't have to go that far. You could just bring in something like React Snap into your Redwood projects and then that could do your pre-rendering for you. So there's, there's a lot of flexibility here in terms of how you can do all of this stuff. The main thing is that it's really, let me, let me explain cells. I think this might kind of help explain kind of the more of like the data fetching kind of aspect. So Redwood has a convention called a cell, and this is the way that your friend is speaking to your backend. So we're talking about graph QL. When you write GraphQL, what you do is you define a query or a mutation in your schema. And then once you define it, you can just write those queries really easily. And what a cell does is you write the query at the top, and then you have four states that your data can be in. So it will basically know whether you are, whether it's empty, whether the data is loading, whether you've gotten an error or whether or not you got the data and you got success. So if anyone's worked with React query, this is a similar kind of idea. We want to make the data fetching declarative. And what this does is it lets you have conventions in terms of how you do your data fetching. So once you have the cell set up, you basically just write the query and then you write your success state. And then the other stuff just gets kind of handled for you. You can put in like a nice spinner or something for loading if you want. And so once you get the data, then you can do whatever you want with it. So that's why I say you can bring in something like React snap and you can figure out the, the pre-rendering yourself. And eventually the pre-rendering will be, will be baked into the framework. So you don't have to do something like that, but that's just kind of where we're at now because we're not at V1 yet. And that's the kind of like last pieces of polished that work that we're still working out. 

DAN_SHAPPIR: So in order to prove, to implement that, what do you provide on the React side? Is it like a custom hooks? Is it higher-order components that you wrap your components in? Or how does it look like from the perspective of the React developer? 

ANTHONY_CAMPOLO: Yeah. So for the perspective of the React developer, they don't really have to think about it. So this is all kind of internals in the framework. It's like, you know, they say the quote unquote magic. So that, that kind of makes some, some developers uncomfortable. And, you know, if, if you ever have to like source dive into it and like, oh, what if, you know, what if it doesn't work? But the main thing is that just, it's, it's already kind of doing the internal plumbing for you in terms of figuring out whether you got an error or not. Like none of this stuff is like super crazy or difficult. It's just obnoxious to have to constantly like write all these conditionals and handle what happens when you get the data and you get an error, you get a success. It's just giving you nice conventions for that. I believe it's using higher work components. That's really more of a question for Peter than for me, but yeah. 

 

Hey folks, if you love this podcast and would like to support the show or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production. And you can go sign up at devchat.tv slash premium. 

 

DAN_SHAPPIR: First of all, I would say that people who really ate magic, what are they doing using frameworks in general and React in particular? Half of React itself is magic to a lot of the people who are using it. It's also interesting to me that so many solutions out there trying to solve essentially the same problem of how to easily create a React-based user interface that asynchronously loads data and is able to show some sort of progress indicator or an error message in the case of failure. It's interesting to see how many, you know, develop how many solutions out there are trying, are coming out trying to solve essentially the same problem. Turns out that it's a difficult problem apparently.

ANTHONY_CAMPOLO: Yeah, that's definitely the main thing is that we're trying to just come up with conventions because like we see everyone doing all this stuff and doing all this repeated work and trying to figure this stuff out. We're like, why don't we just come up with nice conventions that we can all agree on here. So that's, yeah, you're right that there's a lot of duplicated effort going on right now. 

DAN_SHAPPIR: So from your perspective, where is the heart of the, or the main focus or main thrust of the Redwood JS offering? Is it this front end library, is it this backend wrapping and conversion of GraphQL into the database? Is it all of the above strung out together? The fact that it's integrated. What's the core value proposition? Y

ANTHONY_CAMPOLO: eah, the core value proposition is that it will allow one developer to build a complete application quickly and reliably. That is the value proposition. I can really, really speak to this as someone who went through a bootcamp and tried to basically assemble all these technologies myself in our build week. So to give some kind of context here, we have what are called build weeks at Lambda. And a build week is where you are put into a group. Everyone is in different points of the program. So some people are just at the beginning learning HTML, CSS. Some people are learning React or Redux. Some people are learning Node. And all these people in a team and for one week, they have to create a project. These projects are, you know, like saving bookmarks or, you know, a note taking app. Like, you know, your basic kind of crud application with users. So I did three of these build weeks and it, all three of them, we had a team of people working on it for a week and none of those applications ever shipped. None of them ever got to the point where they even functioned basically and what they were supposed to do in terms of the requirements. Once I had learned. Redwood. And I saw kind of what it could do. I realized that I could build any of those projects by myself in a day. So that is the value proposition of Redwood. 

DAN_SHAPPIR: Okay. So let's say I'm sold and it doesn't, it sounds like excellent value proposition. 

AJ_O’NEAL: I, I've got some pushback on that. 

DAN_SHAPPIR: Okay. Go for it. 

AJ_O’NEAL: Go for it because that's what every tagline is for every framework ever.

ANTHONY_CAMPOLO: I know. And that's just why I can just say I lived it. And that's why, that's why I say it's true because I actually lived it and I experienced it myself. So maybe it won't work for everyone else, but for me, that is what happened. 

AJ_O’NEAL: It jives with your brain style. 

ANTHONY_CAMPOLO: It did. Yes, exactly. Frameworks are not tools for your code. Frameworks are tools for your mind. This is what I've gotten for Redwood more than anything else is it gave me a mental model to think about my app. 

AJ_O’NEAL: Dan, you were going to say something? 

DAN_SHAPPIR: Well, my question is really, You know what, forget whether I'm sold or not. Let's say I want to try it out. What's the process? How do I start a Redwood project? 

ANTHONY_CAMPOLO: Yeah, that's awesome. What's really great about Redwood is, so Tom started ReadMe-driven development 10 years ago. And the idea with ReadMe-driven development was you should start by writing your ReadMe and then write your code to make your ReadMe true instead of the other way around. What we're doing with Redwood now is what we're calling tutorial-driven development. It's the same idea where you first write your tutorial and then you write your code to make the tutorial work. So this is partly why I also say it really jives with my, with my mental model is that not only is it a good way to think about your app, they have an incredibly well done sequence of tutorials that teach you how to use it. So what I mean by this is it walks you through how to build up a Redwood app progressively to reveal the framework to you as you're building it. So they start by having you just build pages and layouts and do your routing and do all your kind of front end. Once you get that worked out, then you create a Prisma model and you start doing some database stuff and you do some migrations. And then once you do that, then you create a form and you handle inputs and you do all that. And then you deploy it and then you add authentication. So for anyone who wants to get started in Redwood, it's very simple. Go to this tutorial, start at the beginning and just go when you hit any problems comes to the forums, comes to the discord, ask for help, you'll get like five people who will help you out almost immediately. 

DAN_SHAPPIR: Okay, but in more practical terms, is it like, you know, listening to some of the other projects and frameworks that we've had as guests here on the show, some of them take a more of a see a light type approach like create react app, some take an approach of with Svelte, I think it was more or less just clone a git repo and start with that. So what's the practical process? Well, what do I run some sort of a CLI? Do I do an NPM installer? What's the technical process? 

ANTHONY_CAMPOLO: Yeah, it's very much in the, if you've ever seen the Ruby on Rails demo where DHH builds a blog in like 15 minutes with like lots of scaffold commands and things like that. It's a similar thing. So yes, there's a CLI that has lots and lots of generator commands. So you can generate pages, you can generate layouts, you can generate cells, you can generate services, you can generate SDLs, you can generate almost anything you could possibly think of in a Redwood project. So it's very CLI based, it's definitely based around the idea that you should have to write as little code as possible. You should only have to write code when you absolutely have to, when we can't figure out how to write it for you with the generator. And so yeah, so I would say that's the main kind of workflow for people who come from more CLI based tools, they're going to be very, very comfortable in Redwood. 

DAN_SHAPPIR: And the design of the UI itself, is it usually, if I'm not using something like a Next.js or something, and I'm just using Redwood, is it mostly client-side rendered? How do I fit the designer into the process for building the actual UI?

ANTHONY_CAMPOLO: When I think of how to fit a designer into the UI, I'm not thinking about rendering. I'm thinking about CSS. So I'm not sure I entirely understand your question. 

DAN_SHAPPIR: Well, look, you know, CSS and the HTML are the, are the tools of the trade. I'm what I mean is somebody needs to ultimately design the user interface so that it can be implemented by code. It's implemented by, you know, portions of it, maybe are just straight on HTML with CSS portions of it are, are created by JSX. What's the process of constructing the front end? 

ANTHONY_CAMPOLO: Yeah, I mean, it's the same as any React app you're gonna build. So you're gonna build components in React and then you can write some CSS if you wanna bring in something like Tailwind. You do that as well. We have a Tailwind command that'll configure your Tailwind for you. So the experience of working with the front end should be very, very familiar for anyone who's worked with React over the last three or four years. And it's very hook space, very functional. We don't really do any class components or anything like that. And then like more of the backend GraphQL Prisma kind of stuff. That's what you're really gonna probably gonna have to learn. That's what's gonna be foreign, but the web side should be essentially zero learning curve for someone who already knows React. 

DAN_SHAPPIR: Cool. That sounds like a really good value proposition. 

ANTHONY_CAMPOLO: Yeah. And that's like, for me, it was really cool because I learned so much React in my bootcamp. You know, it was technically called a full stack web development program, but I really felt like it was a front end program with like a tiny bit of backend tacked on at the end. And this is something that I was kind of like bitter about at the time, so I felt like I was getting kind of like jipped in terms of like not getting the full education, but I've really seen the value in that because of the things that I learned in Lambda school in terms of how to work with React, it allowed me to hit the ground running with Redwood because I'd already done all this stuff with create react app. I'd already hit into all the, I already hit all these issues with react router. I'd already tried out Gatsby and next and try to wire those up to databases and get them to speak to, you know, Postgres using some sort of express, you know, API. So like I'd already done all of this. And then when I saw Redwood, I was like, okay, this like, framework's kind of weird. There's like some tools that I don't really know, but like the react stuff makes sense. And, you know, I'm able to kind of go through that. And so as I started hitting more and more of the backend, as like I said, I worked through the tutorial, you just start picking up more and more GraphQL as you go and more and more Prisma as you go. And it just kind of makes sense. I would say if you've never used React before, like you should absolutely not jump into Redwood. You should start with Create React app, you should figure out how to get a Create React app generated, how to make a basic project, how to get that deployed to something like a Netlify or Versel. I would definitely recommend go through that whole process. And then once you have some kind of familiarity with React and the paradigms that are involved in React, you're basically good to go in terms like starting to learn Redwood. 

DAN_SHAPPIR: That's kind of funny though, because at the beginning you said that one of the selling points for, for Redwood is that you don't, you, you don't need to know much in order to get it, to, to use it to build a web app. But now you're saying you actually need to know all that stuff. 

ANTHONY_CAMPOLO: I'm saying you need to know a little bit. I'm saying you need to know Create React app. I think knowing Create React app, I don't think it's really like that huge of a barrier compared to like all the other stuff that Redwood is giving you. So yeah, that's big. I say like just generate one Create React app project and put that online. If you haven't done that, like you're, you're not a React developer, you know? So it's, it's like I say, it's not really meant to like teach you React, it's assuming you have at least a little bit of React knowledge. A lot of people have a little bit of React knowledge, but you can't do anything with a little bit of React knowledge. A little bit of React knowledge doesn't get you anywhere. Redwood is saying, if you have a little bit of React knowledge, we can at least get you somewhere. 

DAN_SHAPPIR: Now, who owns? Sorry, I just wanted to ask who owns Redwood? I mean, is it just a totally open source project? Is there a company behind it who's supporting it? 

ANTHONY_CAMPOLO: Yeah, it's a little bit of both. I say it's a passion project of an eccentric billionaire because that's basically what it is. So Tom is funding it in the sense that he is very well off from the acquisition of GitHub by Microsoft. And he has a Preston Warner Ventures. And so Preston Warner Ventures is funding a handful of the developers on the core team, but all the code is open source project has been and will always be open source. That is the entire point. So there is kind of some funding behind it to kind of like help alleviate the fears people might have of like an open source project, just kind of like disappearing and, and falling off. But, um, but it's not something that there's, you know, it's not, we're not going with like an open core kind of modeling, you know, it's like it's a hundred percent open source. 

AIMEE_KNIGHT: You gave me a good history lesson. I didn't actually know that, um, the person behind Jekyll was the person behind GitHub. 

ANTHONY_CAMPOLO: So he also was the person behind Semper and Tummel.

AIMEE_KNIGHT: Oh, wow. Okay. Wow. That's a lot there. I did not realize that. I feel like maybe I knew about sember, but not Tamil. Okay. I had a question in shoot. Oh, okay. It's come to me now. So you talked about like, what Redwood can do and kind of the different tools that it sits alongside. Are there any like specific constraints that people should be aware of before they decide to kind of like dive into this like things that maybe different things that are common for front end developers that they wouldn't be able to use with Redwood. The answer might be no, but 

ANTHONY_CAMPOLO: when I think of constraints, I started thinking more about the backend because it's like all this kind of set up with like JWT, we don't really have any like session management right now. So that's kind of something that some more advanced developers are kind of running into another, who are looking to build out more sophisticated apps. They want, uh, they want some of the things you not just like a way to pass around a token. But in terms of like the front end, yeah, like I said, like Redwood, it's very forward-facing in the sense that it's meant to enable front-end developers. So you shouldn't hit too many constraints in terms of front end, except for these types of like pre-rendering static site generation things that we've been talking about and that we're still kind of ironing out over the next month or two. So that's gonna be the main thing, is it's still not really good for like generating tons and tons and tons of pages. That's just not really what it's optimized for. At this point, that's why you shouldn't use it that way.

AIMEE_KNIGHT: Now I'm looking at the docs too, because when you were mentioning about deploying to AWS, and if you want like a cloud post-crush instance or something like that, what if someone is more on like, they want to do a document-oriented database? Is that a constraint? 

ANTHONY_CAMPOLO: Yeah. So yeah, this is, this is something I've actually spent a lot of time working on thinking about. So the problem here is that we are using Prisma to do all of our database stuff. And Prisma only works with relational databases at this point. That will most likely change in the future. It's just hard to say when, but the thing is you don't have to use Prisma. Like I don't know if any Ruby on Rails developers ever like rip out active record or if that's like at all a thing you could even do, but that is a thing you can do in Redwood. 

AIMEE_KNIGHT: It is, it is. I know this. I don't recommend it. It was for, it was a learning exercise.

ANTHONY_CAMPOLO: That's so funny, that's exactly how I put it. So you guys know FondaDB, you've had Ebina on the show. I did a project where I ripped out Prisma and used FondaDB instead and basically wrote a bunch of FQL queries inside my services. Yeah, I wouldn't necessarily recommend it, but this is one of those things where if you are, if you have enough perseverance, you can get Redwood to work with any kind of database you want. We will eventually have first-class Mongo support and things like that, but we're not quite there yet.

AIMEE_KNIGHT: Okay. I'm going to say then too, Anthony, is there anything that you really want to talk about that we haven't gotten to? 

ANTHONY_CAMPOLO: Yeah. I would just say that this isn't the only framework doing this. And that to me, I really see Redwood as just one framework among many that are a movement towards figuring out how create these kinds of applications. So going back to Swix, who I already mentioned, he has an idea called the third age of JavaScript, which is that JavaScript is going through. A transition into its third age, the first age being just the creation of the language. The second age being this last decade, basically all of node and all the front end stuff that we now think of your react view and Svelte. And then now we're entering this third age of JavaScript. And this is frequently talked about with things like ESM and tools like Vite and Snowpack, and to me, I really see these frameworks as a huge driver of this transition into the third age. So we're kind of calling them like either, some people call them full stack JavaScript, I like full stack Jamstack, some people kind of like full stack serverless, we didn't really talk a whole bunch about the serverless aspect of this as well. But yeah, just the idea is that single-page applications are amazing and they've gotten us really far, but they're really hard to work with, they're really hard to reason about. And we can create conventions that'll let us continue to work with single page applications in a way that's just like, makes more sense. You know, that's, that's really, it's just about doing all of this more coherently is, is really, is really what I see. So yeah, so like Blitz.js is another popular one in this area. And then Bison is one that not as many people know about, but I think it's really interesting and people should really check out. And I anticipate that we're going to see many, many more of these types of frameworks in. I think people are going to take Nuxt and integrate that with some sort of ORM tool. I think we'll start seeing this in Spelt at a certain point. So yeah, I think that this is just, it's, you know, it's not about like, this is the only way to make apps and this is the one true way. It's not about that. It's just about that for certain kinds of apps that we want to make. This is a really, really nice way to do it and you should consider it. 

STEVE_EDWARDS: So are you familiar with inertia.js at all?

ANTHONY_CAMPOLO: Yes. So inertia JS is a huge inspiration to blitz. So when I talk about blitz JS being another kind of version of redwood, blitz JS is much more monolithic. And so that's why I say it's a lot like inertia because inertia calls itself the modern monolith, right? So the idea that we can have a monolithic development workflow and go back to this really nice Ruby on rails convention over configuration kind of idea. And to me, I think that's, that's really interesting. I am more interested in the approach Redwood is taking. Cause I think by decoupling the front end and the back end, but integrating them nicely with GraphQL, we can get that monolithic development experience, but not with, but without having to tightly couple our front end, our backend there, the idea of things like blitz and inertia are really, there is no API, like at all, they call it the no API layer. And so you're just writing function calls that go directly into your backend and there's no API whatsoever except when that is being kind of like auto-generated for you by a compiler or something. So yeah, I think those are super, super interesting projects. I definitely recommend people check them out. I'm good friends with Brandon, the creator of Blitz. We talk a lot. So I definitely think that, you know, people kind of see some of these different projects as like competitors, but we really see each other as collaborators. 

STEVE_EDWARDS: So it's more a level of coupling, shall we say, that separates the projects and in terms of how tightly coupled they are? 

ANTHONY_CAMPOLO: Yeah, exactly. And so the benefit here is that for something like Blitz, you can host your whole Blitz application really easily and on render. So on render, you can deploy your whole Blitz application and you don't need to do this whole dance where you set up your Netlify frontend and your Heroku Postgres backend and then manage those two dashboards. So this is why there's a lot of benefits to this like much more monolithic kind of experience. Like that's what we're aiming for with Redwood, but without sacrificing the decoupled nature of the front and back end. So we're still trying to get to this kind of single one-dashboard deployment paradigm, and I'm pretty sure we're going to get there. But that's, that's if you're looking for more of that old school monolithic development experience, that's for stuff like Blitz and inertia is really cool. 

STEVE_EDWARDS: Yeah. Cracks me up talking about subjects like this, you know, having started out back early two thousands in the Drupal world where everything was a monolith Drupal WordPress, you know, any type of CMS like that. And then, so you've got your whole pendulum swing where, okay, here we're clear at one extreme where everything's a vertical stack, you got to have, it's all or nothing. And then we go clear the other way you start getting into, initially starts in the mean stack and now it's ME asterisks and, you know, plug in your own front end and we're at the other stream where now you can mix and match all your front ends and your back ends. You can node Laravel or whatever on your back end with view or react or angular yada yada on the front end to guys like Christopher and Andy who are no JavaScript at all, or minimal JavaScript or vanilla JavaScript. And so now it's like we're swinging back towards a monolith side, but with conditions in that it's a monolith, but with flexibility in terms of how you do your front end back end. So it's just interesting to watch that pendulum swing back and forth. 

DAN_SHAPPIR: Well, that and the fact that at the end of the day, we just keep on building crowd applications. You know, the techniques change, but the basic needs more or less remain the same. And, and also the fact that the web essentially was created as a document viewing platform and transformed it into a, an application platform. And you know, we're still paying some of the prices anyway. I'm getting all philosophical here. Is there anything else you still want to mention that we haven't mentioned so far, Anthony? 

ANTHONY_CAMPOLO: Just that we're very community driven. We really love getting people involved, having contributors, helping out people who are building projects with this. So if you just go to redwoodjs.com, you can find links to our Discord or our forums. So for anyone who thinks this stuff is interesting or who wants to check this out and kind of jump in, like check those out. I think that it would be really cool to kind of get as many people involved in the community as possible. So yeah. 

DAN_SHAPPIR: Excellent. 

 

Hey folks.I don't know if you've noticed, but I've been working a lot on figuring out how to help people become the most valuable developers on their teams, or becoming the top 5% of developers in the field. If you're looking to level up, figure out how to contribute more, get the career you want, get the career that you want that will support the lifestyle you want, then you should check out the Most Valuable Dev Summit. I've invited some of my friends across the community, people that you've heard of, people that have worked on systems that you use on a daily basis people who have invented new ways of doing things over the years in programming, and I've asked them one question, and that question is, how do you become a top 5% developer? How do you become one in 20 of the best developers out there? And so we're gonna go ahead and have that conversation with them in interviews on the Most Valuable Dev Summit, and you can find that at summit.mostvaluable.dev.

 

DAN_SHAPPIR: And since we've apparently lost both Amy, although she has actually provided us her picks in advance, I assume it will be edited properly into the show. And we've lost AJ because we understand we had some sort of a production issue. It's just me and Steve who are left with you. So Steve, do you want to start with picks or should I? 

STEVE_EDWARDS: No, go ahead. So I'm going to fall back into my pics of classic movies that I keep seeing on Turner on TV. And my choice for this time is goes back to I think it's 1953 is Jimmy Stewart and Doris Day and the man who knew too much. Really good movie just is about Jimmy Stewart's vacationing in Morocco and runs into a guy who turns out to be an FBI agent about an assassination plot and his kid gets kidnapped and taken to London to keep him quiet about the plot and everything that. So yeah, 1956. And I must say, Doris Day is definitely not unpleasant to look at and to listen to. She was a very beautiful woman. And then interesting side note, there was a spoof made probably 15, 20 years ago with Bill Murray called, The Man Who Do Too Little. And the whole gist of that one is the same lines, except he's playing a game and doesn't realize that he's fallen into a real, some sort of spy story or something like that 1997 was when that was made. So I haven't seen that one yet, but I've seen all about it and read all about it. So anyway, classic movie, The Man Who Knew Too Much. 

DAN_SHAPPIR: Excellent. So now I'll go with my own pick. My pick is a pick that's on the one hand really interesting and deserves to be picked. On the other hand, I'm slightly ambivalent about it. And it's the State of JS survey results for 2020, which, yeah, which recently came out. On the one hand, it's really, I think, useful to know where the market is at, what technologies are being used, what your colleagues and other people in your field are thinking about and using. It certainly is a strong indicator of things you need to know in order to be attractive in the workplace, if nothing else. But on the other hand, I always think that, you know they use whatever tools they want and I'll use the tools that work for me. So it's interesting, but I take it with a pinch of salt, I guess. What I found especially interesting is that in the section on technologies, it turns out there is something like a big four, four and a half, five technologies that kind of dwarf all the rest, which are Webpack, React, TypeScript express, which is interesting that it's still way up there. And also kind of just for testing. And these are like at the top right-hand quadrant, far above everybody else. All the others are either on the left side, technologies like Angular and Gulp, or on the right side, but at the bottom or lower down at least, technologies like Vue, Rollup, or really at the bottom the bottom of the left side, the technologies that are apparently dying out, like Amber and ClosureScript and Meteor that I know, people are trying to revive it but apparently not so much traction yet. So it's interesting in that regard. Also interesting is that they have a rating of podcasts and we are at number 6 on the top, which on the one hand is really cool, but on the other hand means that we have where to aspire to. So if you're a faithful listener, and please do tell your friends about us and make sure that they listen as well. Hopefully they'll enjoy it and next year we'll be higher up. So that would be my pick for today. Anthony, what about you? What are your picks or pick or whatever? 

ANTHONY_CAMPOLO: Yeah, sure. I also just like to hook into what you said. I'm not at all surprised to see Express on the list because what I learned No quote unquote node in my bootcamp. Or when you learn node in any tutorial, they all start off with express pretty much off the bat. No one is really taught how to use node HTTP. You just are like given express from the very start. So that's why a lot of people don't even know how to write node without writing express. That's why express is not going away for a long time. 

DAN_SHAPPIR: Oh yeah, I'm not surprised at all that it's at the top in terms of the vertical axis is have use. So I'm not at all surprised that a lot of people have used Express. What is interesting is that so many people still have such a positive view about Express that way more than many other technologies like React Native or Puppeteer or even Vue.js. That's the part that I find interesting, that not only is Express so commonly used, is that it's still so well loved. 

ANTHONY_CAMPOLO: Yeah, I think it's just because of the simple API. People like simple APIs. Going back to why we like Redwood, you know? So yeah, thank you guys so much for having me. I'm someone who's been listening to this show for so many years and have gotten so much value for it. So thank you guys for continuing to do what you do for creating such a fantastic resource for JavaScript developers. In terms of my picks, I will pick, so I was talking earlier about how we have a lot of different frameworks in this kind of area and I kind of think of the full stack Jamstack as like the big bucket. So I'm doing a podcast with a friend of mine, Christopher Burns called the FS Jam, the full stack Jamstack podcast. So if you just go to fsjam.org. or if you go to twitter.com slash FS Jam, ORG, you'll be able to find us. We're talking to a lot of people involved in Redwood along with other frameworks like Blitz. You've had Brandon on a couple of times, and we're getting, we've had Chris on for, or Chris Ball on for Bison. So it's really fun. And we're kind of like standing out and getting more people on from companies like Fauna and Prisma and people on the Amplify team. So, you know, I just think there's like so much interesting stuff happening here. And that's kind of like our hub for where a lot of that activity is happening. And then aside from that, just check me out on dev.to. I blog a lot. My kind of general handle is AJC Web Dev. And that's also my Twitter handle or anything like that. So yeah. 

DAN_SHAPPIR: Cool. And I'm browsing the list of episodes on your podcast and it's definitely interesting and I'll definitely give it a listen. So thank you very much for that. I see you've got 12 episodes so far. So, you know, we are at the episode like almost 500. So you definitely have something to aspire to. 

ANTHONY_CAMPOLO: We're going at two a week right now because we've got so many guests. So we'll see, I might eventually start to out run you guys. We'll see. 

DAN_SHAPPIR: Oh, good luck. Anyway, you did give your contact information. So that's excellent. And guess that, AJ, I see you're back. Do you have any picks for us before we wrap up? 

AJ_O’NEAL: No, I don't. Well, thanks for coming for the last five days. 

ANTHONY_CAMPOLO: Thanks for always being a voice of contrarian. I highly, highly appreciate it. And I was hoping I'll get more pushback from you. 

AJ_O’NEAL: Yeah, I'm sorry. I if it weren't for the issue with my client that they kind of need. Well, everything always feels urgent with them, but sometimes it is. You never know. That's a good way to manage people, to tell people it's urgent. They get it done. So anyway, yeah, I'm sorry. I couldn't participate. 

ANTHONY_CAMPOLO: Well, that's all good. 

DAN_SHAPPIR: OK. Then with that, I guess I'll wrap up this show. So thank you everybody for listening and bye bye. 

STEVE_EDWARDS: Adios.

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y dot com to learn more.