Ep 30: Anthony Campolo RedwoodJS Contributor

Joshua Proto: Welcome listeners to another episode of the Talking Serverless podcast. I am your co-host, Josh Proto, and I am here today with Anthony Campolo, who is a contributor to Redwood JS, and the host of the FS Jam podcast.

Background
Joshua Proto: Q: How did you get to be where you are right now?
Anthony Campolo: I'm someone who went through a front end focused coding boot camp and learned a lot of React and some Node and that whole kind of world. After learning that, I got really interested in this framework called Redwood JS, which is a framework built with React, and is architected specifically to run in a serverless way; it basically takes your whole back end and puts it into one big Graph QL handler. So it's Graph QL, and it's serverless. It's a really interesting blend of technologies.
Joshua Proto: "...it's an opinionated, full stack serverless web application framework for building and deploying Jamstack."

Q: What is Jamstack? What does it mean to be an opinionated, full stack, serverless web application framework?
Anthony Campolo: The way I think of Jamstack is, it's the front end, and serverless is the back end. You have all these applications now that are built with a static front end. So it's one giant bundle of JavaScript that essentially is built and then deployed. You want to have serverless stuff to glue together all the functionality you lose from not having a database. Redwood is trying to be opinionated because it's going for a Ruby on Rails type thing; a fully integrated full stack solution. So it has an ORM, which is Prisma, and it has Graph QL for your front end to talk to your back end. It's serverless because it gets deployed on an AWS lambda via something like Netlify, or Versal. So these platforms are enabling front end developers to build Jamstack applications. And the way they're doing that is with these lambdas under the hood.

Q: What is this really allowing people with front end skills to do using things like Redwood JS, and what is the lift from just using Jamstack to using Redwood?
Anthony Campolo: The main thing is that it makes it really easy to connect to a database. It makes it better for more data intensive applications, because it's all wired up for you. And it's scalable, because it's all on AWS lambdas. There's been a handful of different applications built with it. There's one called 'Repeater.Dev', which is a background CRON job, and there's 'Tape.Sh', which is for screencast recordings. If you go to the awesome Redwood repo, there's a whole list of the eight or so production applications that have been built with it. It's amazing to be able to build these things just with one developer. It's enabling developers to build more just by themselves.
Q: You had taken some education from a more front end-oriented boot camp. Was it something that they were leading you towards, being really passionate about serverless and budding technologies? Do you think there should be more of an emphasis on teaching serverless for individuals to be able to do these production applications themselves?
Anthony Campolo: This is something that really is a personal topic for me having gone through the boot camp. So we didn't learn Redwood, we just learned basic React. We didn't use Gatsby or Next, or any sort of framework. You really want people to come out of it understanding the fundamentals of the thing you're trying to learn, so they don't want to bet on this one really specific technology. Redwood's still pretty new so it makes sense, but I feel like it needs to eventually get you to where you can have a tool that you can really make use of. The problem is, once you get to the end of your bootcamp education, you've learned all this React stuff, but if you want to actually put that together to make a real production application, there's more steps to it that you didn't get to. A lot of that stuff gets filled in by a framework like Redwood, so I think it would be useful to get exposed to these things. I don't know if it necessarily needs to be in the curriculum, but I know for me it was very useful to get this extra boost from the framework, having struggled with just 'vanilla' React.

Applications in the Serverless World
Q: How many instances in the real world are you just going to be using 'vanilla' React and not using a framework or meta framework in that sort of way?
Anthony Campolo: That's definitely the trend for where a lot of these things are going; people are building abstraction layers on top. I think if you look at the history of these tools it makes sense, because React was not intended to be a full framework that you could build a whole application with, it was intended to just be the view layer. It's a third of your application, but the front end has just eaten more and more of the functionality that needs to happen in an app. So Redwood is trying to find that balance of getting a snappy SPA feel, while still being able to connect to a database and have your CRUD operations.

Q: In the serverless world, do you see a further use for abstraction tools? Is the continued use of abstraction going to help from the developer experience, or does it get to a point where it's actually hindering either their expertise and being able to go into the weeds and fix things? How do you find that balance?
Anthony Campolo: You don't want to hide too much with abstractions, because ultimately it's still running on physical computers and physical locations on the globe somewhere. We can build all these abstractions on top, but they're going to leak through it at certain points. So it's about laying the developer breakdown to the level they need to when they need it. We learned how to use Netlify and Versal, which is the highest level of abstraction in the sense that you can deploy your whole application with just a click of a button, but you have no idea what is going on behind the scenes, so you can't go any further than what those services are going to provide you. You need to really think, what are front end developers actually working with; what are the applications they're actually writing and what are the constraints they're working with?
Q: In your experience and in your mind, do you think there's a good partitioning of how much experience or comfort one should have in their front end skills with abstraction versus being able to be in the weeds?
Anthony Campolo: There could definitely be a risk if you don't know how to apply the abstraction; a risk of people wanting to, once they learn a framework, apply it to every single problem. And this is where we see problems with trying to scale things like Ruby on Rails, because you'd have this big monolith, and you need to know how to actually break that stuff apart to make good use of it. It's about having abstractions that are powerful and useful, but also educating the developers about what the abstractions are for and knowing what is being done for you. It's nice to have a framework that can do all this stuff for you, but if you're not aware of what it's doing, you'll get yourself into trouble really quickly. So I think it's an education thing; understanding the tool and understanding when you would want to use a really high level of abstraction and when you would want to use something that's lower level to build up your own pieces.

Industry Knowledge
Q: At what point do you think is a good time to be looping oneself in with these tools that allow you to have some levels of abstraction, making it easier for you to reach production level? What would you suggest people start learning first, if they're coming from this front-end background?
Anthony Campolo: I think you want to start off with the most basic you can. So I'd start off with just Create React and see what you can get from there. Then you'll want to add in React Router and then see what you can get from there. I find that once you do that, and you start to find the challenges that come with routing, then you start to look at things like Gatsby and Next JS, because they handle things like your project structure and how your pages map to your components. I think those are good ones to learn, Gatsby and Next, because they've been around a lot longer than Redwood, they've proven themselves to be pretty stable technology, and they both are backed by companies that have large workforces. For Redwood, I wanted to actually be able to have impact on an open source project. So I specifically looked for something that was going to be in the early growth cycle. It's not something that is necessarily recommend to a complete beginner; once someone's messed around a bit with Gatsby and Next is when I would say you should start looking at something like Redwood.

Q: From your journey, what has been an interesting overlap of skills/ expertise, and how do you like to integrate that into what you're doing currently?
Anthony Campolo: If you talk about the connections between music and programming, in a real sense, they have absolutely nothing to do with each other; nothing I learned from music or education has anything to do with coding. But what it does have in common is, for me, how do you explain a very abstract idea? We have these words talking about music, just like we have words to talk about programming, but the words aren't the 'thing'; the thing is something much more complex that you're trying to get across. And I always liked teaching music theory, because it was the most abstract, but at the same time it's a fully coherent system. So once you understand the system it makes a lot of sense. It's the same thing with programming; what a loop is, and what variables are and what objects are... You start to learn the pieces, then you can start to put them together, play with them and make new arrangements. That's kind of where I think some of the cross section is there. And the passion for communicating; everyone listens to music, just like everyone uses computers, but very, very few people take the time to ask how it works.
Joshua Proto: "If you can find community around what you're learning, or what you're building, then I think it just feeds back in a positive feedback loop, making everyone else who's participating more skilled, and more willing to put in the work to advance themselves."

Q: Are there any use cases that you've that you've heard about that were particularly inspiring or interesting to you, or used in a way that you thought was a bit different than you were expecting?
Anthony Campolo: I guess it's just seeing people building out more and more complex things. There's ones that use machine learning, and there's some that are data visualisation. And when you think of a static site that's using lambdas, usually they have a blog or something like that, but it's actually being used to build a lot more full-featured, data-heavy, interactive type applications. It's all being done with lambda and being deployed in various different ways. All the frameworks started looking at different ways to deploy, which serverless targets you can deploy with and what the user experiences working with those tools. There's so much happening; now we have edge handlers, so you have lambdas that are on CDNs. And that's where a lot of this I think is going now; you don't just have your front end blog that's globally distributed, you have your business logic that can also be globally distributed as well.

Future
Q: Where is the next level of optimization or growth pulling Redwood? Are there other areas that people are really finding it attractive for?
Anthony Campolo: It's definitely expanding out into a generic deploy target, because there's this idea of the universal deployment machine. And this idea is to just deploy the application with GIT push, and that would be the entire deployment pipeline. I think it's about how we get further and further into the full stack, so once you have your business logic globally distributed, the last thing you need is for your persistence to be to be globally distributed as well. This is where you get into things like Fauna DB, which is what's called 'serverless database'. They're starting to call themselves a Data API, but they are a globally distributed database that uses the Calvin protocol, which is this new cutting-edge consensus protocol. That's where I think this stuff goes next; if you can get the database then that's the whole thing. You have a full application that is fully serverless.

Q: It seems like you've been doing a tonne of contributions to Redwood JS, and really understanding its vision and where it's going; are you fully invested in contributing and talking about Redwood and all of its affiliates? What other stuff are you working on/ are you passionate about?
Anthony Campolo: I can get interested by a million different things; really focusing on something specific was something I forced myself to do, and that was really focusing on React and learning React really well. That opened up the opportunity to be able to contribute to something like Redwood, and I went really heavily into that for a long time. I've invested a lot into contributing to Redwood and learning about it, but I don't want to only know this. I don't want to be pigeonholed into one area and away from my own learning and knowledge. So I'm interested in Spelt and View... I'm really interested in Dino, which is the new JavaScript, server side language from the creator of Node; I've done a Dino talk, I did a few talks about Nuxt, and I'll be doing another talk about the composition API in a week or two. So I see myself as being in the front end world, in React, and wanting to expand out to other front end things as well as back end things like server side and database stuff.

Open Source
Q: As someone who does a lot of ops and operations everywhere, I'm interested to get some insight into the life cycle and feeling of what it means to work on an open source project. How do you get involved? Is it similar to anything else you've ever worked on or worked with before?
Anthony Campolo: The project I'm on now reminds me a lot of the camp I used to work at; it's tight knit. It's people doing something that they're really passionate about, and doing it because they're passionate. If you can find projects like that, that's really what you want to get involved in. Anyone who wants to get into development, getting into open source, the benefits are absolutely insane, but you have to really know what projects you're going to pick to contribute to. There's such a wide range and huge spectrum of these different projects, from a single person doing it in their spare time to a team of people who are supporting large, Facebook sized companies. You really want to be careful with where you're going to be focusing your time and your energy, and make sure that you're getting something out of it, because you're mostly doing it for free. That's the whole thing with open source; all the stuff that I've done with Redwood hasn't been paid. But it's led to opportunities that have paid back the time I put into it tenfold. And for me, I can say the trade off was absolutely worth it; 100% no regrets, but there could have been a million other alternate universes where it didn't work, and it could have been exploitative and things like that. It's really hard to actually get a handle on what's important and what's not. Podcasts and Twitter have been the two things that really helped me understand what's going on because you can be a fly on the wall to so many conversations, and you need to pay attention to a lot of these conversations to get the sum total and understand all the dynamics at play.

Q: How do you tell this if is a good project to invest time and energy into or if they have a good community?
Anthony Campolo: Look at where the community is congregating. Look at where people are asking questions; GitHub is going to be a hub for a lot of things. Look at whether they are responding to questions at all, first of all, and if they are, how fast are they responding to questions, how helpful are they, how open is the community to newcomers coming in and asking potentially really dumb, unresearched questions? How much patience do they have for that? There's a lot of a lot of signs that you can look for. So I would say those are the things to look for; how the maintainers of the project actually engage with the community. You can see whether it seems healthy or not. You'll be able to see the patterns very quickly, especially for stuff that's on GitHub; I can go back months or even years and see everything. That's the great thing about open source, that there's a lot transparency. And in that respect, you also have to be wary of getting lost in information overload. It's almost too much transparency, because once there's so much information, no one wants to bother sifting through it. But if you take the time, it's pretty easy to suss out whether a project is like welcoming or not.

Q: What else would you like to mention? What else would you like to talk about? The things that you're working on, your ideas of where Redwood or some of these other frameworks and technologies you've talked about are going in the future, which you're most excited about?
I think it's gonna be slowly eating away more and more functionality of traditional monolithic application. So Ruby on Rails, or WordPress; we're going to slowly figure out more and more patterns and ways of simplifying how to build these applications in a serverless way. It's being attacked from various different angles from open source frameworks, and also from companies that are implementing services. I see so much innovation happening. It's always pitted as a winner take all type of thing; I don't think it necessarily has to be that way. There's so many benefits to working with this serverless stuff, and so many things that it simplifies for you that we should always be looking for ways to leverage this technology. And as other people do that, they're going to be forced to, because competitors are gonna be doing things faster, better and cheaper. You can get faster, better and cheaper, if you are willing to take the time to change your mental model; the cost is rewiring your brain to figure out how to write these kinds of applications. But once you get it there, then it seems to be the way to go.
Q: Do you think we will eventually see the 'death' of the mono repo? Will there still be a place for them or will they always be baked into the technology lifecycle?
Joshua Proto: “In my world there's a lot of moving to cloud/ serverless and break things apart. It's mind-blowing to me that some of these patterns are still happening for these lifecycles. Its a very different mindset of efficiency and deliverability.”
Anthony Campolo: Redwood is serverless but it's also in some sense a mono repo, because its one big project that has front end and back end. You have a web folder and an API folder, but that's not the whole project. The actual think is your logic being deployed on distributed on global architected, micro-service type thing, so you have something that we can think about as a single project, but that doesn't actually exist as a physical monolith on a single computer that can't be scaled up. So we can get away from that paradigm while keeping the mental model. That's what Redwood is going for- it wants to allow developers to develop in a way that's like a monolith, but it reality it's being deployed as a global serverless thing. The jury is out on whether it will work or not but that’s the experiment and what it's trying to do.

Q: If people are interested in learning more about you and your work, where can they find you online?
Anthony Campolo: 'AJC web dev' is my general handle, so that will be on twitter and GIThub. Dev.2 is where I do most of my main blogging, so those are the platforms where you can check out what I'm doing. I'm really passionate about creating content and communicating about these sorts of things so I'm putting out stuff all the time. My podcast is FSJam.org.