Anthony Campolo RedwoodJS Contributor

Episode Description

Anthony Campolo discusses Redwood JS, Jamstack, serverless abstractions, open source contribution, and the future of full-stack serverless development.

Episode Summary

In this episode of Talking Serverless, Anthony Campolo—contributor to Redwood JS and host of the FSJam podcast—walks through how he transitioned from a front-end coding bootcamp into the serverless world through Redwood JS, a framework that packages React, GraphQL, and Prisma into a serverless-first architecture deployed on AWS Lambda via platforms like Netlify and Vercel. The conversation traces the relationship between Jamstack and serverless, with Anthony framing Jamstack as the front end and serverless as the back end that glues together the functionality static sites lose without a traditional server. A significant thread runs through the episode on education: both hosts share backgrounds in teaching, and they explore when developers should move from vanilla React to meta-frameworks, how bootcamps can better prepare students for production-level work, and the risks of leaning too heavily on abstractions without understanding what's underneath. Anthony offers practical advice on evaluating open source projects by examining community responsiveness and transparency, and he reflects on how unpaid contributions to Redwood opened doors that paid back tenfold. The episode closes with a forward-looking discussion on globally distributed business logic, serverless databases like FaunaDB, and whether the serverless paradigm will eventually absorb the functionality of traditional monolithic applications.

Chapters

00:00:00 - Introduction and Anthony's Serverless Journey

Josh introduces Anthony Campolo, a Redwood JS contributor and podcast host, and asks about his path into serverless development. Anthony shares that he came through a front-end coding bootcamp focused on React and Node, then discovered Redwood JS, which bundles a React front end with a GraphQL-based serverless back end running on AWS Lambda.

The conversation quickly moves into what Redwood JS actually is: an opinionated, full-stack framework designed for Jamstack applications. Anthony breaks down how Jamstack represents the static front end while serverless handles the back-end glue, and explains that Redwood integrates Prisma for database access and GraphQL for communication between layers, all deployed through platforms like Netlify or Vercel.

00:03:07 - Empowering Front-End Developers with Serverless

Josh asks what Redwood JS practically enables for developers with primarily front-end skills. Anthony explains that the framework makes it straightforward to connect to databases, handle authentication, and build data-intensive applications, all while benefiting from the scalability of AWS Lambda. He highlights several production apps built with Redwood, emphasizing that individual developers can now ship full applications on their own.

The discussion shifts to whether coding bootcamps should teach serverless tools and full-stack frameworks rather than siloing students into front-end or back-end tracks. Anthony argues that bootcamps are right to focus on fundamentals first, but notes the gap students face when they finish: they know React but lack the tooling to build production-ready applications. Frameworks like Redwood help bridge that gap.

00:07:09 - Meta-Frameworks, Abstractions, and Their Risks

Josh raises the concept of meta-frameworks—abstraction layers built on top of tools like React—and asks where the balance lies between helpful abstraction and dangerous obscurity. Anthony agrees that abstractions are powerful but warns they inevitably leak, and developers need the ability to drop down to lower levels when problems arise. He points out that platforms like Netlify let you deploy with a button click but leave developers unaware of what's happening underneath.

They explore the tension between convenience and understanding, with Anthony noting that misusing abstractions—like relying on Prisma without understanding the SQL it generates—can lead to serious issues. The takeaway is that education around tooling matters as much as the tooling itself, and developers should know when to reach for high-level tools versus building from lower-level components.

00:12:56 - Learning Paths: From Vanilla React to Frameworks

Josh brings up the common question of how long it takes to learn JavaScript, noting that it depends heavily on context and prior experience. He then asks Anthony for a recommended learning progression for front-end developers interested in moving toward production-level work. Anthony suggests starting with Create React App, then adding React Router, and eventually graduating to established frameworks like Gatsby or Next.js before considering something newer like Redwood.

Anthony explains that he chose Redwood specifically because he wanted to contribute to an early-stage open source project rather than because it was the most beginner-friendly option. He also mentions Vue equivalents like Nuxt and Gridsome, reinforcing the idea that the progression from basic library to meta-framework applies across the front-end ecosystem, not just within React.

00:17:23 - Music, Education, and Abstract Thinking

Both hosts discover shared backgrounds in education—Anthony was a music teacher before transitioning into development. They explore the parallels between music and programming, with Anthony arguing that while the domains share nothing technically, the skill of explaining abstract systems transfers directly. Understanding music theory as a coherent system mirrors learning programming fundamentals like loops, variables, and objects.

Josh extends this to the broader point that comfort with complex systems in one discipline builds the mental flexibility to tackle complexity in another. They discuss how the serverless community's accessibility—through learning resources, mentors, meetups, and collaborative culture—creates a positive feedback loop that accelerates skill development for newcomers entering the field.

00:21:10 - Open Source Culture and Redwood's Community

Anthony credits Redwood's open source community and its creator, Tom Preston-Werner (co-founder of GitHub), as key factors in the project's appeal. He describes how GitHub's collaborative tools enable decentralized teams to form organically, and how participating in open source conversations exposes contributors to high-level architectural thinking across multiple production use cases rather than just a single application.

The conversation touches on how open source involvement can serve as a springboard for visibility, leading to podcast appearances, conference talks, and published articles. Anthony emphasizes that the benefits of open source contribution can be enormous but aren't guaranteed, and contributors need to be strategic about which projects they invest their unpaid time in.

00:25:59 - The Future of Serverless and Globally Distributed Applications

Josh asks where Redwood and the broader serverless ecosystem are heading. Anthony introduces Tom Preston-Werner's vision of a "universal deployment machine" where a simple git push handles the entire deployment pipeline. He identifies globally distributed databases—like FaunaDB with its Calvin consensus protocol—as the final piece needed to make a fully serverless application stack, where business logic and data persistence are both distributed globally.

They also discuss the expanding landscape of deployment targets, from Netlify and Vercel to the Serverless Framework and edge handlers that place Lambda functions on CDNs. Anthony sees serverless gradually absorbing the functionality of traditional monoliths like Rails and WordPress, predicting that organizations adopting serverless patterns will outpace competitors in speed, quality, and cost efficiency.

00:32:34 - Getting Involved in Open Source: Practical Advice

Josh asks Anthony for concrete guidance on how developers should evaluate and join open source projects. Anthony recommends looking at community health indicators: whether a project has active forums or Discord, how quickly maintainers respond to questions, how they treat newcomers, and whether the community feels welcoming. He compares the experience to working at a summer camp—tight-knit and passion-driven.

Anthony also warns about information overload, noting that the transparency of open source means there's almost too much to sift through. He stresses that while the benefits of contributing can pay back investment many times over, contributors should be realistic about the fact that most work is unpaid and outcomes aren't guaranteed. Podcasts and Twitter, he adds, are invaluable for staying oriented in the fast-moving open source landscape.

00:38:07 - Monoliths, Mindsets, and Closing Thoughts

The final segment tackles whether monolithic architectures will eventually disappear. Anthony offers a nuanced view through Redwood's approach: the framework preserves a monolith-like developer experience with a single project containing web and API folders, while the actual deployment is distributed and serverless. The goal is to keep the mental model simple while leveraging global infrastructure underneath.

Josh and Anthony close with reflections on whether the serverless mindset is something taught or innate, and Anthony shares where listeners can find his work—on Twitter and GitHub as AJC Web.dev, blogging on Dev.to, and hosting the FSJam podcast. Both emphasize the importance of community education and content creation in driving serverless adoption forward.

Transcript

00:00:00 - Josh Proto

Welcome listeners to another episode of the Talking Serverless podcast. I am your co-host Josh, and I'm here today with Anthony Campolo, who is a contributor to Redwood JS and the host of the FSJam podcast. Anthony, thank you so much for joining us today.

00:00:18 - Anthony Campolo

Hey, thanks for having me. Really stoked to be here.

00:00:21 - Josh Proto

Yeah, you're super welcome. I appreciate you taking the time today to meet with us. I'd love to start out as I usually do and ask you to give us a rundown of your experience with serverless. How did you get to be where you are right now?

00:00:36 - Anthony Campolo

Absolutely. I went through a front-end-focused coding bootcamp and learned a lot of React and some Node. After that, I got really interested in this framework called Redwood JS, which is built with React and is architected specifically to run in a serverless way. It basically takes your whole backend and puts it into one big GraphQL handler. So it's GraphQL, it's serverless, and it's this really interesting blend of technologies.

00:01:16 - Josh Proto

Very cool. I had not heard of Redwood JS before getting on this call, so I did some research. Redwood JS says it's an opinionated, full-stack serverless web application framework for building and deploying Jamstack. We've had some people talk about Jamstack in the past.

I'd love for you to maybe explain a bit of what Jamstack is. What does it mean to be an opinionated, full-stack, serverless web application framework? That was something that really stuck out to me.

00:01:44 - Anthony Campolo

Yeah, it's the perfect combination of buzzwords, right? It's interesting because Jamstack and serverless are related, but they're also kind of separate. The way I think of it is that Jamstack is the front end and serverless is the back end. So what I mean by that is you have all these applications now that are built with a static front end. It's one giant bundle of JavaScript that 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 where it's a fully integrated, full-stack solution. So it has something that's kind of like an ORM, which is Prisma, and it has GraphQL 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 Vercel. So these platforms are enabling front-end developers to build these quote unquote Jamstack applications.

00:03:02 - Anthony Campolo

And the way they're doing that is with these lambdas under the hood.

00:03:07 - Josh Proto

Oh, well, that definitely sounds really exciting, being able to empower everyone with the power, flexibility, and scalability of Lambda. I'm biased, but I think serverless in general will only add to what can get delivered, the quality of the products, the quality of the applications, and lower the time to market.

What sort of things have you seen in practice? What is this really allowing these people with front-end skills to do? What are they now able to do using things like Redwood JS? What is the lift from just using Jamstack to using Redwood?

00:03:43 - Anthony Campolo

Yeah. The main thing is that it makes it really easy to connect to a database, so for things like authentication and having users. It makes it better for more data-intensive applications because it's all wired up for you. Like you said, 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, which is kind of like a background cron job type thing. And then 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 made so you can build these things just with one developer. It's enabling developers to build more by themselves.

00:04:42 - Josh Proto

Fantastic. So this is really a solution that allows an individual to build their own production application. That's great.

You took some education from a more front-end-oriented bootcamp. Was this something they were sort of leading you down towards? Is this going above and beyond being really passionate about serverless and budding technologies? What I'm trying to get at is whether you think there should be more emphasis on teaching serverless and teaching ways for individuals to build these production applications themselves, rather than siloing out, "You're only a front-end person" or "You're only a back-end person." That's something I see all the time. I think in the cloud world you're doing everything, being a full-stack cloud developer, but I'm interested to hear your take on that.

00:05:37 - Anthony Campolo

Yeah. This is a really fantastic question, and it was almost the main topic of one of the last episodes I did with Monarch on the Full Stack Jamstack podcast. This is something that is a personal topic for me, having gone through the bootcamp. We didn't learn Redwood. We just learned basic React, and we didn't use Gatsby or Next. We didn't use any sort of framework. I think this is the right approach in the sense that you really want people to come out of it understanding the fundamentals, whatever the fundamentals of the thing you're trying to learn are. So they don't want to bet on one really specific technology, and Redwood is still pretty new. So it makes sense. But I feel like it needs to eventually get you somewhere where you can have a tool you can really make use of. Because the problem is, once you get to the end of your bootcamp education, you've learned all this React stuff.

00:06:38 - Anthony Campolo

But if you want to actually put that together to make a real production application, there are a lot more steps 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 after struggling with vanilla React.

00:07:09 - Josh Proto

Definitely. I also question how many production environments or jobs you're going to be getting out of the education space when you're only using vanilla React. Unless you're the only developer on the project and it's greenfield and you're doing it yourself, you're only going to do what you know. How many instances in the real world are you really just going to be using vanilla React and not using a framework or a meta-framework?

00:07:42 - Anthony Campolo

Absolutely. It's interesting that you use the term meta-framework, because the trend I see is people building abstraction layers on top. If you look at the history of these tools, it makes sense. React was not intended to be a full framework that you could build a whole application with. It was intended to be just the view layer, like the V in MVC. It's a third of your application, but the front end has eaten more and more of the functionality that needs to happen in an app. Redwood is trying to find that balance of getting that snappy SPA feel while still being able to connect to a database and have your CRUD operations and all that.

00:08:34 - Josh Proto

Completely. I was turned on to the terminology of meta-framework from your podcast. I hadn't really thought of it that way or heard it used to describe some of these frameworks in that area. I like that you bring up layers of abstraction. When I think of serverless and one of the value propositions it has, and some of the more popular serverless frameworks, I only see that in this space there's going to be better and better tools that allow you to abstract out either writing the CloudFormation or even the templatization of best practices. I'm wondering how you think about the serverless world. Do you see further use for abstraction tools? Is the continued use of abstraction going to help from the developer side, like the developer experience, or does it get to a point where it's actually hindering their expertise and being able to go into the weeds and fix things? Where is that balance?

00:09:36 - Josh Proto

How do you find that balance?

00:09:38 - Anthony Campolo

Yeah, you don't want to hide too much with abstractions because ultimately all this stuff is still running on physical computers and physical locations on the globe. We can build all these abstractions on top, but they're going to leak through at certain points. So it's about letting the developer break down to the level they need when they need it. And I want to go back to something you said about teaching serverless technology. We learned how to use Netlify and Vercel, which is kind of the highest level of abstraction in the sense that you can deploy your whole application with a click of a button, but you have no idea what is going on behind the scenes. You don't know what a serverless function or a container is, or any of that. You don't even encounter that kind of stuff, so you can't go any further than what those services are going to provide you. So we need to expand into what is actually happening under the covers and expose those pieces that will allow front-end developers to make better use of all the tools underneath, because people who are into serverless could be super into distributed message queues and all this really technical infrastructure stuff.

00:11:01 - Anthony Campolo

Supposedly this is stuff that's meant to enable front-end developers. So you need to really think about what front-end developers are actually working with, where the applications are actually running, and what constraints they're working with.

00:11:14 - Josh Proto

Understood. In your experience, do you think there's a good partitioning of how much experience or comfort one should have with front-end skills and abstraction versus being able to be in the weeds? Is it a 40/60 split? Is it a 50/50 split? Is that too much if you're relying half on abstraction? Do you think that is maybe a bit too much or has too much risk?

00:11:44 - Anthony Campolo

Yeah, there could definitely be a risk if you don't know how to apply the abstraction. There's definitely a risk of people wanting to, once they learn a framework, apply it to every single problem. This is where we see problems with trying to scale something like Ruby on Rails, because you have this big monolith and you need to know how to break that stuff apart to make good use of it. So it's about having abstractions that are powerful and useful, but also educating developers about what the abstractions are for and knowing what is being done for you. You could use Redwood without necessarily using Prisma, because Prisma does all the fancy database stuff for you. But you can get yourself into trouble if you don't really understand the SQL that it's generating. So 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.

00:12:44 - Anthony Campolo

So I think it's an education thing of understanding the tool and understanding when you would want to use a really high-level abstraction, and when you would want to use something that's lower level and build up your own pieces.

00:12:56 - Josh Proto

You just made me think of an interesting point. You talked about how it's important, especially when you're first learning, to understand the fundamentals of JavaScript, whatever that may be. I recently had a friend on Twitter post, "Is two months long enough for me to learn JavaScript?" It's like, well, that's such a subjective question. If you don't know any other programming languages, there are people who spend eight months full time being able to have a solid idea of the fundamentals and getting an internship. If you know three other programming languages, maybe it's only going to take you a couple of weeks. Are you learning JavaScript to develop a production-ready application to scale a business, or are you using it for a side project?

00:13:48 - Josh Proto

It's very challenging to answer that sort of question, but it's one that I see in my network. Tying it back into these levels of abstraction, maybe I have two questions. First, at what point do you think it's a good time to loop oneself in with these tools that allow you to have some levels of abstraction, maybe making it easier to reach production level? Second, what would you suggest people start learning first if they're coming from a front-end background? Is it Redwood? Is it something else? I'm interested in your thoughts.

00:14:29 - Anthony Campolo

Sure. I think you want to start off with the most basic you can. So I'd start with Create React App and see what you can get there. Then you'll want to add in React Router and 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, 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. You'll run into a lack of structure as you try to build more complex applications. I think those are good ones to learn because they've been around a lot longer than Redwood and they've proven themselves to be pretty stable technology. They are backed by companies with large workforces. There's also a large community and many learning resources. Those are a really great way to expand beyond just your basic React.

00:15:44 - Anthony Campolo

And if you're in Vue, you have Nuxt and Gridsome as the equivalent of that. Now for Redwood, the reason I wanted to get into it is because I wanted to actually be able to have an 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 I would necessarily recommend to a complete beginner. It's once someone has messed around a bit with Gatsby and Next that I would say you should start looking at something like Redwood. For me it was because I saw where the framework was and where it could potentially go, and I found it fascinating. So I spent a lot of time learning it, getting familiar with it, and becoming fluent with it, and then eventually getting to know the team behind it and going to meetups and things like that. It's really useful to be able to get involved in an open source project.

00:16:44 - Anthony Campolo

And then what was the second question?

00:16:46 - Josh Proto

I believe you sort of answered it. It was around which one you should start with, which I think you answered with looking at one of the more established frameworks rather than jumping straight into Redwood. So thank you for that.

I appreciate you humoring me with these questions about the education process. I used to be in education for over five years, so it's always something that's very important to me: the learning process, educating the next generation of coders, architects, and serverless experts. It's all a very impassioned initiative for me.

00:17:23 - Anthony Campolo

Yeah. I actually have an education degree. I was a music teacher before I started doing all of this.

00:17:30 - Josh Proto

Oh, amazing. One thing I love to hear about is where people have started, where they've come from, and how that has influenced what they're doing now. What do you think about your past experience as an educator, specifically in music? Music is also very close to my heart. I study Indian classical music, Hindustani North Indian classical music, and Nepalese folk music. It's something I'm pouring a lot of time into. I'm also doing software as well, so I definitely think there is a lot of overlap and complementary skills from your journey. What has been an interesting overlap of skills and expertise, and how do you integrate that into what you're doing currently?

00:18:09 - Anthony Campolo

Yeah, it's funny. So many people talk about the connections between music and programming. In a very real sense, they have absolutely nothing to do with each other in that nothing I learned from music or education has anything to do with coding. But what it does have in common is how you explain a very abstract idea. We have words to talk 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. I always liked teaching music theory, especially because it was the most abstract, but at the same time it's a fully coherent system. Once you understand the system, it makes a lot of sense. It's the same thing with programming. When you understand what a loop is, what variables are, what objects are, you start to learn the pieces and then you can start to put the pieces together, play with the pieces, and make new arrangements with them.

00:19:21 - Anthony Campolo

So yeah, that's kind of where I think of some of the cross-section being there, and the passion for communicating these kinds of things. Everyone listens to music, just like everyone uses computers, but very few people take the time to ask how it works. I always ask, "Why does this work the way it does?"

00:19:46 - Josh Proto

Absolutely. I can certainly relate to that. I fully agree that if you understand how complex systems work in one discipline, even if it's not the same or you're not describing the same thing at all, it gives your mind the elasticity and the confidence to jump into and learn another complex, abstract idea that can get translated into actionable results and expertise in a completely different domain.

I always talk to people who are interested in serverless, and one piece of feedback I get from those who are just getting into serverless is that it's not necessarily easy to start, but it's accessible. There's a level of accessibility to the learning resources, the ability to practice a lot, and conversations with people who are willing to be mentors and collaborate.

00:20:45 - Josh Proto

I'm also hearing a similar thing now with being able to go to meetups with Redwood JS. That's an amazing thing. If you can find community around what you're learning or what you're building, it feeds back in a positive loop, making everyone who participates more skilled and more willing to put in the work to advance themselves.

00:21:10 - Anthony Campolo

Yeah, for sure. The open source nature of it and the community aspect are some of the biggest things, because the framework was created by Tom Preston-Werner, one of the original creators of GitHub. What we think of today as open source and open source culture is entirely based around GitHub, because GitHub is not just a place to keep your code. It's a tool to enable developers to collaborate on code. By creating tools specifically meant for collaboration, you can then have decentralized teams form by themselves, using these tools and sitting in on the conversations that are happening. You can see the comparisons to other frameworks and see people who are actually using Redwood in production, and what they're thinking about in terms of authentication. You get to see so much that's really high level, because it's not just a single production application.

00:22:26 - Anthony Campolo

It's a project that multiple production applications are going to be built on top of, so it's a larger superset of cases. You have to think about an even larger span of things than you would if you were just deploying one application. It's been a really fascinating thing to see. It's led to me being able to do podcast interviews like this. I've done a lot of meetup talks about it as well. I've started to write articles, and it's incredible how it can be used as a springboard into visibility.

00:23:07 - Josh Proto

Absolutely. That's truly fascinating. The nature of open source is that there are so many projects going on, and they have so much potential. Many of them are being used and are very useful. I'm really interested: are there any use cases you've heard about or learned about that were particularly inspiring or interesting to you, or used in a way you thought was a bit different than you were expecting? Maybe anything particularly relying on the serverless aspects, if that was a consideration for the use case. That would be a bonus, but it doesn't have to be. I'm interested to be a fly on the wall in those discussions. What have you found most intriguing?

00:23:49 - Anthony Campolo

Yeah. The thing that is very fascinating from a serverless perspective is that, like I said, the way the framework is architected, it's serverless by default. So essentially everyone who's putting any of these things into production is doing it serverless. There are questions now like what is the maximum amount of data you can have in a single Lambda, or what's the running time. Netlify is introducing background functions, so you can have 15-minute long-running tasks. I guess it's just seeing people build out more and more complex things. There was one that used machine learning, and there are some that are data visualization. When you think of a static site that's using lambdas, you usually think of a blog, but it's actually being used to build a lot more full-featured, data-heavy, interactive applications. As I said, it's all being done with Lambda out of the box and being deployed in various different ways.

00:25:03 - Anthony Campolo

It was originally architected for Netlify, which is running lambdas under the hood. Then we had Vercel added on. There are people who figured out how to do it with the Serverless Framework. I imagine people will start doing it with Architect and Begin. There are other frameworks doing this too. All the frameworks are looking at the different ways to deploy and which serverless targets you can deploy with, and the user experience of working with those tools. There's so much happening now. We have edge handlers, so you have lambdas on CDNs. That's where a lot of this is going now, where not just your front-end blog is globally distributed, but your business logic can also be globally distributed as well.

00:25:59 - Josh Proto

Yeah, completely. That's really fascinating to hear. I always love hearing about whatever technologies people are most intimately working with, where they see the technologies going, what current problems they're trying to overcome, and where they think it could be going in the future.

You just mentioned the distribution of business logic. Once that happens, what do you think the next thing is? Where is the next level of optimization or growth for Redwood? Are there other areas people are really finding it attractive for? It'll be exciting to see it work with some of these other frameworks or people finding ways for it to work with these other frameworks. I know on the consulting side of things at Serverless Guru, we use a ton of Serverless Framework.

00:26:51 - Josh Proto

We do some alternative ones as well. I think I'm seeing a lot of tools optimize for the whole breadth of frameworks. I think that makes not only the frameworks more appealing, but also these tools as well. So it's really exciting to hear all the different options available.

00:27:10 - Anthony Campolo

Yeah, it's definitely expanding out into trying to be a generic deploy target because there's this idea that Tom has. He calls it the universal deployment machine. His idea is that he wants to be able to deploy his application with just a git push, and that would be the entire deployment pipeline. So I think it's about how do we get further and further into the full stack. The database would really be the final thing. Once you have your business logic globally distributed, the last thing is you need your persistence to be globally distributed as well. This is where you get into things like FaunaDB, which is what's called a quote unquote serverless database. I don't know if you're familiar with this at all. They're starting to call themselves a data API, I think that's their new branding, but they are a globally distributed database that uses the Calvin protocol, which is this new cutting-edge consensus protocol.

00:28:20 - Anthony Campolo

It's kind of like Paxos. They use Raft and it's like MongoDB, so it's a document-type database. That is what I think is where this stuff goes next. If you can get the database, then that's the whole thing. You have a full application that is fully quote unquote serverless. That's a really fascinating thing to see.

00:28:51 - Josh Proto

Oh, completely. I fully agree. That does sound really fascinating. It seems like you've been doing a ton of stuff with 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 its affiliates and directions, or what other stuff are you working on and passionate about? I know I have too many side projects personally, both technology and not so technology related. I'm interested to hear what other things you're working on or ideas you're working toward.

00:29:31 - Anthony Campolo

Yeah. I'm someone who can get interested in a million different things. Really focusing on something specific was something I had to force myself to do. For me, that was really focusing on React and learning React really well. Then that opened up the opportunity to be able to contribute to something like Redwood. I went really heavy into that for a long time. I've invested a lot into contributing to Redwood and just learning about it. The framework, in a lot of ways, is just getting started. We're going to hit V1 sometime within the next couple months, and then it actually starts. But I don't want to only know this. I don't want to be pigeonholed into one area, just for my own learning and knowledge. So I'm interested in Svelte and Vue. Vue is now transitioning into Vue 3 with the composition API, which is going to, in a lot of ways, mirror the transition React went through over the last two years of going from class components to hooks and more of a functional component style.

00:30:43 - Anthony Campolo

So I'm really interested in that. Then Svelte is a whole different kind of thing. It's a compiler, not the same kind of framework as React or Vue. That's really cool. Then I'm really interested in Deno, which is the new JavaScript server-side language from the creator of Node. I've done a Deno talk and I did a Vue talk about Nuxt, and I'll be doing another talk about the composition API in a week or two. I see myself as being mostly in the front-end world in React and wanting to expand out horizontally to other front-end things and vertically to other back-end things like server-side and database stuff.

00:31:33 - Josh Proto

Totally. That's good to know. We have a number of people on our team who have been intrigued by Deno and have played around with it. I don't know if we've written any articles on it yet on the Serverless Guru side, but I think we had some drafts. I think that's really cool. It's a really cool piece of tech. I'm really interested to see what more happens there.

I'd love to ask a little bit more from you. As someone who does a lot of ops and operations, I'm interested to get some insight into the lifecycle and the feeling of what it means to work on an open source project. If someone was interested in starting to get involved, how do you get involved? Do open source projects also have crunch times around the holidays, like we are experiencing right now? Is it similar to anything else you've ever worked on or worked with before?

00:32:34 - Anthony Campolo

You know, I will one day write a whole book about open source, I would imagine, because it's a lot of things. It definitely reminds me of the camp I used to work at, because it's tight-knit and it's people doing something they're really passionate about and doing it because they're passionate. If you can find projects like that, that's what you want to get involved in. I would say to anyone who wants to get into development that getting into open source has benefits that are absolutely massive, but you have to really know what you're getting into. You have to know what projects you're going to pick to contribute to, because there's a huge range and spectrum of projects, from a single person doing it in their spare time to a team of people supporting a company, to large companies like Facebook-sized companies.

00:33:33 - Anthony Campolo

So it's the whole spectrum. You really want to be careful where you're going to be focusing your time and energy and make sure that you get something out of it because you're most likely going to be doing it for free. That's kind of 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. 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 out and it could have been exploitative and things like that. So it's really complicated. It's really nuanced. The sooner you can start doing it, the better. But at the same time, you also need to suss out what is actually happening in open source, because it's massive and it's really hard to get a handle on what's important, what's not, what's going up, and what's going down.

00:34:40 - Anthony Campolo

That's where podcasts are so important. I can't stress that enough. Podcasts and Twitter have been the two things that have really helped me understand what's going on. You can be a fly on the wall for so many conversations, and you need to pay attention to a lot of these conversations to get the sum total understanding of all the dynamics at play.

00:35:05 - Josh Proto

You know, it's sort of like asking the question of how you start a business. What is it like to start a business or work in a company? I'm looking forward to when you release your memoirs on the open source days of Redwood JS. So maybe a tidbit there: is it easy to tell, like, "Oh, this is a good project to invest time and energy into"? They have a good community, I'd imagine. It's probably easy to tell if people are engaged and there's a team or a community around it. But I haven't done much open source contributing myself, so I'm interested to hear what you think.

00:35:45 - Anthony Campolo

Yeah. You just want to look at the community.

00:35:47 - Anthony Campolo

Look at the forums. Look at whether they have a Discord. Look at where the community is congregating. Look at where people are asking questions. Obviously GitHub is going to be a hub for a lot of things. Look at how fast they are responding to questions at all, first of all. If they are, how fast are they responding? How helpful are they in how they respond to questions? How open is the community to newcomers coming in and asking potentially really dumb, unresearched questions, and how much patience do they have for that? There are a lot of signs that you can look for. The hard part is knowing what to look for. I would say those are the things to look for: see how the maintainers of the project actually engage with the community. You can see whether it seems healthy or not.

00:36:41 - Anthony Campolo

You'll be able to see the patterns very quickly, especially for stuff that's not like GitHub. You can go back months or even years and see everything. That's the great thing about open source: there's a lot of transparency. 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 welcoming or not.

00:37:18 - Josh Proto

Completely. Thanks for your insight on that. A great point to bring up is the information overload part, because there are so many projects one can contribute to in the world, front end, back end, depending on what your thing is, cloud. If you're able to jump in and assess how fast they answer questions and how well they work with others, you have a really good idea of whether you want to contribute to this and be part of this team. Do you also feel motivated by the people you're working with? In my experience, it's the people you work with or are associated with. For me, that really drives me forward and gets me up in the morning.

00:38:07 - Josh Proto

But I digress. We may be running up to the end of our time, and I don't want to keep you over. So I'll open it up. What else would you like to mention? What else would you like to talk about, either the things that you're working on or your ideas of where Redwood or some of these other frameworks or technologies you've talked about are going in the future? Which are you most excited about?

00:38:34 - Anthony Campolo

Yeah, I think it's going to slowly eat away more and more functionality of what you would think of as a traditional monolithic application. So your Ruby on Rails or your WordPress. We're going to slowly figure out more patterns and ways of simplifying how to build these applications in a serverless way. It's being attacked from different angles by open source frameworks and by companies implementing services. By all of these virtuous cycles going on, I see so much innovation happening. It's always pitted as a battle of a winner-take-all type thing, and I don't think it necessarily has to be that way. There are 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. As other people do, they're going to be forced to, because your competitors are going to be completely outrunning you and doing things faster, better, and cheaper.

00:40:00 - Anthony Campolo

That's something that seems to be true of serverless: you can get faster, better, and cheaper if you are willing to take the time to change. The cost is rewiring your brain to figure out how to write these kinds of applications. But once you get there, then it seems to be the way to go.

00:40:22 - Josh Proto

I definitely love that. One thing you mentioned that I'm really interested in your opinion on is whether we will eventually see the death of the monorepo. Will there still be a place for them, or will it always be baked into the technology life cycle? If you have one, do we need to eventually 100% get rid of this and get rid of it faster than what's currently happening? In my world, there's a lot of "We have this monorepo, we need to move to cloud, we need to move to serverless, we need to break it apart." People have never really done that before, or even some startups that I've had the privilege of learning a bit more about. It's like, oh yeah, this crazy blockchain technology is all monorepo and we don't really know. There's multiple versions of overlap and all this sort of stuff. It's mind-blowing to me that some of these patterns are still happening.

In the serverless world specifically, the way we're planning around these projects and their life cycles is very different. We have a different eye and mindset of efficiency and deliverability. I'm interested in your thoughts. Do you think this mindset is something that's taught? Is it something that's innately baked into certain developers and then they're easy to flip over to serverless? Will we ever have 100% adoption? The difficult questions.

00:41:54 - Anthony Campolo

Yeah. It's really interesting you say that because Redwood is serverless, but it's also in some sense a monorepo, because it's one big project that has your front end and back end. You have a web folder and you have an API folder. But that's not the whole project because the actual thing is logic being deployed on this distributed, global microservice-type architecture. 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 be scaled up. It's about getting 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 in reality it's being deployed as this global serverless type thing. The jury is out on whether it's going to work or not, but that's the experiment and what it's trying to do.

00:43:17 - Josh Proto

For sure. I think the jury is definitely out, and it's probably going to take a couple of years, at least, for them to come back, convene, and actually give us an answer. I'm always of the model that we need to get one wheel rolling within a scooter before we can build a car. That's a design mindset. I definitely think it's an effective process and framework for approaching the problems, getting people used to the functionality rather than the idea, if that can't happen first.

Anthony, if people are interested in learning more about you, your work, and things that you like, or if there are recordings of your meetups or talks or blog posts on Redwood or anything else, where would they be able to find you?

00:44:05 - Anthony Campolo

Sure. AJC Web.dev is my general handle. That'll be on Twitter and on GitHub. Dev.to is where I do most of my blogging. Those would be the platforms where you can check out what I'm doing. I'm really passionate about creating content and communicating about these kinds of things, so I'm putting out stuff all the time. If you're interested, I've got the podcast too. Thanks so much for having me on the show. I think it's really great what people like you are doing in terms of communicating this stuff about serverless, because as I was saying, the benefits are there, but people really need that education, and stuff like this is super invaluable.

00:45:02 - Josh Proto

Yeah, I fully agree. I want to encourage all of our listeners: if you're finding any of this that we've been talking about with Anthony very intriguing or maybe just learning about it for the first time, definitely check out his podcast and some of his work. I think it could be really interesting and is a good learning resource. It can hopefully act as a tributary into a wider form of knowledge and education about these topics related to serverless and technology and the advancements we're seeing. It's always cool to see that. For me, the future is a serverless future, whether in ideology or practice. Always very exciting.

You're very welcome, Anthony. It was great to have you on. Thank you all the listeners of Talking Serverless for joining us again for another podcast.

00:45:50 - Josh Proto

And we will see you all next time. This is Josh Proto signing off.