Anthony Campolo Returns
Josh Proto interviews returning guest Anthony Campolo about updates in his work on RedwoodJS, StepZen, serverless technologies, and coding education
Episode Description
Anthony Campolo returns to discuss StepZen's GraphQL gateway, RedwoodJS updates, serverless deployment challenges, accessibility, and code school education.
Episode Summary
In this return visit to the Talking Serverless Podcast, developer advocate Anthony Campolo walks through the evolving landscape of full-stack JavaScript development, starting with his new role at StepZen, a managed GraphQL API gateway that stitches multiple backends into a unified schema. The conversation traces how StepZen complements RedwoodJS by extending its self-contained GraphQL architecture outward to third-party services, then shifts into the practical difficulties of making frameworks portable across serverless platforms like AWS Lambda, Azure, and Cloudflare Workers, where differences in runtime semantics and server implementations like Apollo Server create real friction. A significant portion of the discussion centers on Redwood's accessibility work, particularly the challenge of making single-page application routers announce navigation changes to screen readers, a problem the team solved with a root announcement component inspired by Gatsby's research. The episode also explores AWS meta-frameworks—SAM, CDK, and Amplify—comparing their declarative versus imperative approaches, before turning to the state of code school education through Campolo's candid perspective as a self-described "Lambda School dropout." Throughout, both hosts emphasize the value of documenting architectural decisions, meeting developers where they are with familiar tools, and centering real user experiences when building technology.
Chapters
00:00:00 - Introductions and StepZen Overview
Josh Proto welcomes Anthony Campolo back to the podcast, noting Anthony's new role as a developer advocate for StepZen alongside his continued work with RedwoodJS. Anthony shares his excitement about returning and building on their previous conversation's themes.
Anthony explains that StepZen is essentially a managed GraphQL API gateway with a CLI and built-in deployment. It allows developers to stitch together multiple backends and data sources into a single unified GraphQL schema, making it particularly useful for Jamstack and React front-end projects that need to integrate services like Shopify, Airtable, and various headless CMS platforms. He connects this back to his open source journey, noting that his Redwood work ultimately led to the StepZen opportunity.
00:04:48 - GraphQL Fundamentals and StepZen's Role in Redwood
Anthony describes how he's been building projects, blogging, and live-streaming to deepen his understanding of StepZen, mirroring his earlier approach with Redwood. He explains GraphQL at a foundational level—a query language for APIs where you send JSON-like objects with keys and receive populated data back, supporting full CRUD operations through queries and mutations.
The conversation turns to how Redwood and StepZen complement each other architecturally. Redwood is a self-contained full-stack framework where React speaks GraphQL to a Prisma-backed API, but it doesn't easily reach beyond itself. StepZen acts as an additional link in the chain, enabling a Redwood app's API to communicate with external services without developers needing to manually translate REST APIs into GraphQL schemas. Joshua notes the value of this approach for avoiding vendor lock-in and expanding possibilities for adoption.
00:10:13 - Framework Flexibility and Full-Stack Jamstack
Anthony discusses StepZen's technology-agnostic approach, explaining it works with Vue, vanilla JavaScript, and other front-end frameworks, not just React. The goal is to meet developers halfway with whatever technology they already know, reducing the barrier to learning GraphQL. He introduces his concept of "full-stack Jamstack" or FSJam.
Joshua picks up on the "soup" metaphor, connecting it to real-world team dynamics where hyper-siloed development can damage projects. He argues that from the user's perspective, the experience should be seamless regardless of the underlying complexity. The discussion shifts toward how serverless functions and Lambda originally served as the glue for stitching APIs together, with Anthony noting that tools like StepZen aim to make that integration smoother and more automatic.
00:13:30 - Serverless Portability Challenges and Runtime Differences
Anthony goes deep on the technical challenges of making Redwood portable across serverless platforms. He explains that Redwood's entire backend API was designed as a single Lambda function—what AWS guidelines would call a "Lambda monolith" anti-pattern—and discusses the tension between different Node.js runtimes across Lambda, Azure, and Google Cloud Functions, each with different semantics around context, event, and callback objects.
The discussion gets more granular around Cloudflare Workers, which run on V8 rather than Node.js, creating confusion for developers who assume JavaScript portability. Anthony identifies Apollo Server as the specific breaking point for cross-platform deployment, explaining ongoing work to extract and swap out server implementations using projects like GraphQL Helix. He describes how Redwood already decoupled Apollo Client, allowing React Query as an alternative, and similar server-side decoupling would enable smoother multi-platform deployment.
00:19:40 - Deploy Targets, Render, and the Road to V1
Anthony outlines the Redwood deployment landscape, noting that Azure and Cloudflare support isn't on the V1 roadmap but exists as self-directed exploratory work. He highlights Render as the most promising current deploy target, describing it as a full-stack Heroku alternative that solves the problem of splitting front-end and back-end hosting across different platforms like Netlify and Railway.
The conversation shifts to Redwood's V1 priorities: full TypeScript support, baked-in accessibility features, and integrated tooling like a VS Code plugin. Anthony explains the framework's ongoing struggle with deterministic builds caused by a complex Yarn monorepo setup. Joshua probes into the accessibility work specifically, setting up a deeper discussion about why designing for accessibility benefits everyone and shouldn't be treated as optional.
00:23:37 - Accessibility in Single-Page Applications
Anthony credits Dominic Saadi for spearheading Redwood's accessibility efforts and explains the fundamental challenge: single-page applications handle navigation through client-side JavaScript rather than server requests, which breaks screen reader assumptions about page transitions. When a user clicks a link in an SPA, the screen reader doesn't know navigation occurred and can't announce the new page.
The team's solution was a root announcement component that finds the H1 on each page and announces it, drawing on research from the Gatsby team and Marcy Sutton. Anthony argues strongly that solving accessibility at the framework level is far better than expecting individual developers to figure it out themselves. Joshua shares a personal anecdote about a colleague demonstrating their screen reader experience, noting that 70-80% of their web browsing involves poorly accessible sites. Both agree that centering disabled users' experiences produces better products for everyone.
00:30:51 - AWS Meta-Frameworks: SAM, CDK, and Amplify
The conversation pivots to AWS infrastructure tools, with Anthony drawing parallels between JavaScript meta-frameworks like Redwood and AWS meta-frameworks like the Serverless Framework. He discusses his experimentation with SAM and CDK, noting their potential to merge into a more powerful combined tool and explaining their philosophical differences: CDK is code-first and imperative, SAM is YAML-based and declarative, and Amplify approaches from the application layer.
Joshua shares the Serverless Guru consulting perspective, explaining that they recommend the Serverless Framework nine times out of ten due to its third-party plugin ecosystem, but acknowledge SAM or other tools may be better for specific language requirements like C# or Java. Anthony gives a shout-out to ARC and Begin as innovative CloudFormation abstractions. Both emphasize the importance of documenting why specific tooling decisions were made so future team members understand the rationale.
00:42:31 - Code Schools, Lambda School, and Developer Education
Anthony unpacks his "Lambda School dropout" identity, explaining it captures both an endorsement and a critique. He describes Lambda's model of zero-upfront-cost education and the inherent churn that comes with constant program iteration, including recent layoffs. He shares that Lambda's curriculum and vetting process were valuable, but his career ultimately came from dropping out to pursue Redwood full-time.
Joshua broadens the discussion to the state of developer education overall, referencing Serverless Guru's intern cohort program that emphasized learning by doing rather than hand-holding. Anthony highlights Mapping, a company run by friends from the Redwood community that organizes learning hackathons for code school graduates still seeking jobs, providing valuable feedback loops for both learners and tool creators. Both agree that low barriers to entry are essential for accessibility but that some form of vetting—like basic coding exercises—ensures applicants understand what they're committing to.
00:51:57 - Wrap-Up and Community Resources
Joshua signals the conversation is winding down, and Anthony shares key resources: the RedwoodJS website, StepZen's site, his FSJam podcast, and community spaces like the React Podcast Discord and Open Source Discord at events.dev. He emphasizes the value of cross-community collaboration between the serverless and full-stack JavaScript worlds.
Joshua mentions enjoying Anthony's recent "To Fork or Not to Fork" podcast episode about Blitz potentially forking Next.js, which Anthony compares in significance to the Node.js fork and Ethereum's fork. They tease a future conversation about blockchain topics before closing out, directing listeners to the show notes for all links and handles mentioned throughout the episode.
Transcript
00:00:05 - Josh Proto
Hello, hello. Welcome back to the Talking Serverless Podcast. This is your host, Josh Proto. I am super excited to welcome back one of my favorite guests that we've interviewed, Anthony Campolo. Anthony Campolo is a developer advocate for StepZen and RedwoodJS. They are the host of the FSJam podcast and a great open source supporter. I'm super happy to have you back on. I really enjoyed our conversation last time, so thanks so much for taking the time to meet with us.
00:00:32 - Anthony Campolo
Thank you so much for having me back. I'm really excited. I very much enjoyed our last conversation as well. We hit on so many interesting topics that I'm really passionate about, and we'll get to expand on them in this episode. Thanks for having me.
00:00:45 - Josh Proto
You're very welcome. Last time we talked so much about RedwoodJS and the state of open source and getting involved in open source. Since then, I have experimented and dabbled with a couple more open source projects, more on the blockchain side than the serverless side.
00:01:06 - Anthony Campolo
Some guys are getting into blockchain as well, so I'd be curious to hear about that.
00:01:10 - Josh Proto
Yeah, totally. I've been seeing certain parts of the blockchain world starting to embrace serverless and GraphQL. When I saw that you're now doing advocacy work for StepZen and how it's leveraging GraphQL, I'd love to hear about it. I don't know too much about it. Why is it valuable, and how is it using GraphQL? What's going on here?
00:01:33 - Anthony Campolo
Absolutely. If you want to be descriptive about it, it's a managed GraphQL API gateway. That's essentially what it gets you. It makes it really easy to spin up a GraphQL server, have an endpoint, and do anything you want with it. On top of that, it lets you stitch different backends and different data types together into one unified schema. It's a really cool tool for integrating different pieces together, which is why the blockchain GraphQL stuff is interesting. It's the same idea of having all these different chains trying to talk to each other. It's like a mesh. It leverages GraphQL and gives you a nice CLI with deployment built in, and they host that API for you. There are other open source projects doing things like this, like GraphQL Mesh.
00:02:32 - Anthony Campolo
But you would have to run that yourself. Here, not only do they have this whole thing built out, but you can get your endpoint up and have a whole project going really quickly.
00:02:42 - Josh Proto
Fantastic. That sounds super useful. Are there any current projects with key moments or key use cases? Is it a lot of blockchain, or is it a variety of use cases right now?
00:02:57 - Anthony Campolo
Not blockchain. It's more in the Jamstack and React front-end area right now. It's about getting these different backends, whether it's Shopify or Airtable or these different e-commerce tools and headless CMS, and stitching that all together into one unified thing for your front end. That's a lot like what Redwood was when we talked about Redwood in our previous episode.
For anyone who hasn't heard that one, Redwood is a React framework that has a GraphQL middle layer that lets your front end and back end talk to each other. I had been doing work with Redwood, and then Anant, who's the CEO of StepZen, saw what I was doing and reached out to me. It's been really cool because when I first talked to you, I didn't even have a job. I was coming out of my bootcamp and trying to make it in this whole thing, and it all paid off.
00:04:00 - Anthony Campolo
One of the things you asked me in our previous episode was what I'd gotten out of open source and whether it was worth it. I said it paid off 100%, a million times. There were a lot of alternative realities where it might not have worked out that well. I'm very lucky it worked out the way it did, and it's been a way to expand into all this other stuff that's happening in the GraphQL ecosystem.
Because Redwood is opinionated, it gives you a whole stack of all the pieces you need to have a full-stack GraphQL project. It just gives you that, so you can take it and run with it and not think about it too much. That's really nice. But at the same time, you have a hard time grokking the difference between Apollo and urql.
00:04:48 - Anthony Campolo
That's a really hard question to answer. You have to dig into this stuff to start to understand it. That's what I've been working on over the last couple of months and doing a similar thing to what I did with Redwood. I'll build out projects, blog about them, do live streams, and do podcast interviews. Now I understand StepZen, I can build with it, communicate about it, and start dialoging with people. Does it make sense to them? What are they looking to get out of it?
00:05:23 - Josh Proto
Wow, fantastic. I'm super happy to hear that. If working in open source was already a 100% return for your time, now it's maybe 200% or even more. It's great to see it really pays dividends. There's a saying I believe to be true: to the degree that we can create our own future, we don't need to predict it.
Open source is interesting because there are a lot of opportunities to create the features or the future of the projects you're working on. If you can demonstrate your ability to do that, the world is your oyster. It's really interesting to see how Redwood is leveraging GraphQL and working around that.
00:06:11 - Josh Proto
Do you think Redwood was always going in this direction? What are some exciting things going on with Redwood that you're looking forward to?
00:06:27 - Anthony Campolo
Redwood was originally architected for GraphQL, and having worked with Redwood set me up really well to understand what was happening with StepZen because GraphQL is a spec. For people who've never gotten the GraphQL 101, it's a query language for APIs, and it's a way for your front end to talk to your back end. You do that by throwing what looks like JSON objects back and forth. If you imagine a JSON object with just the keys, not the values, you say you want a person and then their name, and you'll get back name: Josh. That's the whole deal. It's very simple, and you can also do mutations. So you can do create, read, update, delete all within this query language.
00:07:27 - Anthony Campolo
For Redwood, that query language is how your React front end talks to your backend via Prisma. That's a step in the chain, but GraphQL is what gets you from the front all the way to the back. Tom and Peter created Redwood based on their experience building Chatterbug, a language learning platform with a React front end speaking GraphQL to a Rails backend. They wanted to build a framework better integrated for these kinds of technologies.
What it doesn't really do is let you reach out beyond itself. Redwood is self-contained. It's a full-stack framework, like Ruby on Rails. But part of the Jamstack idea is, how do we pull in other APIs to do all this other stuff and create all this other functionality? That's where something like StepZen comes in because you can get this gateway that becomes another step in the chain.
00:08:23 - Anthony Campolo
So your Redwood front end can speak to the Redwood API, and that API can talk to your StepZen API, and that API can talk to all this other stuff. It opens you up to a wider world of possibilities for what you can do with a Redwood app. As a Redwood developer, you don't want to write all the logic to translate all these different REST APIs into a GraphQL schema. That's not something you have the time or experience to do. That's what StepZen lets you do. It gives you the ability to write these schemas and plug in endpoints to do that translation.
00:08:58 - Josh Proto
Very cool. In the cloud services world, you still hear concerns about vendor lock-in. To what degree is it really a problem? How do you account for applications that are tightly coupled to certain ecosystems or architectures? Sometimes that expands to who you have working on the projects and everyone's preferences for how they develop and whatever developer experience standards you're setting.
Being able to have your systems play nicely with what could happen in the future matters because we can never predict exactly what's going to happen. If we have access to a whole, infinite amount of APIs, that's probably better for the ecosystem long term anyway.
00:09:52 - Josh Proto
That's really exciting to see because I remember hearing from you and seeing a lot of positive things happening with RedwoodJS. If you're able to crack that nut like they seem to be doing, then you have way more possibilities for mass adoption. That's one of the golden desires of open source projects.
00:10:13 - Anthony Campolo
What's cool is that it can work with anything you want in terms of different front-end technologies. You can use it just as easily with Vue or even vanilla JavaScript. We're going to have lots of docs with examples of different ways you can use it so that whoever comes to it can be met halfway with whatever tech they already know, because it's a big ask to learn GraphQL and then this tool built on top of it.
If you can meet people halfway, it's like, all right, if you know React really well, then I can get you halfway there because we have a React front end speaking to all this GraphQL stuff in the back. We can set that up for you and give you good defaults. Then you can write most of the front-end stuff yourself.
00:10:59 - Anthony Campolo
That's a similar idea to what Redwood was to a certain extent. It's really cool. It allows us to think in a similar mindset of the full stack and the front end and back end, how it all fits together into this soup that is FSJam, as I like to say, full-stack Jamstack.
00:11:18 - Josh Proto
I love it. I like the idea of full stack as a soup, a mesh of interconnectedness. I've seen teams hyper-siloed out. Even when people are responsible for different elements of a traditional backend or front end, that disintegration can negatively impact projects in every way imaginable.
Approaching something that is a soup from the user's standpoint matters. If you're developing a complicated web app, the user ideally has a seamless experience. They're not seeing everything connect and trace and break down, the fail-safes activating, rerouting the request, pulling out a cache someplace, and getting it delivered. That's a very interesting point.
00:12:16 - Josh Proto
You mentioned new developments with Jamstack or ways to leverage serverless components. As Talking Serverless, I'm excited to hear a bit about that, or for you to elaborate for everyone listening.
00:12:33 - Anthony Campolo
Absolutely. Since these are all just APIs on the open internet, it's easy to stitch them together with serverless functions, as we think of them traditionally. That's where this all started with Lambda. The idea was: I want to write functions in whatever language I want, as long as that language is JavaScript or Python, and eventually they add more languages. The real idea was to write code in the language that makes sense to you and deploy it to the world.
You can create Google Cloud Functions that stitch together different parts of your backend. Ideally, you shouldn't have to do that. That's the kind of stuff we're doing to make all this work in a nice, seamless way. You don't have to, but if you want to, that's a thing to do.
00:13:30 - Anthony Campolo
I've been going very deep down this rabbit hole because we're trying to make Redwood as portable as possible. Everyone talks about vendor lock-in and whether your thing can work cross-platform. It was designed for AWS Lambda. The idea is that your entire backend API is one giant Lambda function. If you listen to a lot of serverless people, you'll frequently hear them say not to do this. There's a serverless guide that came out on AWS recently, and the first anti-pattern is the Lambda monolith. We are the embodiment of that anti-pattern, but it works.
You can put that online, hit it, and it gives you information back. But you eventually hit a point where you need to start breaking it up into smaller pieces to get it to work the way serverless is supposed to, as your listeners and serverless people probably know.
00:14:37 - Anthony Campolo
There's a strange tension between the different types of JavaScript you're writing, or the different types of Node you're writing. Lambda versus Azure versus Google are all basically giving you Node, but at different versions. They have slightly different semantics in terms of what they pass in: context object versus event object versus callback object. You also handle requests and responses differently because Google gives you Express, which isn't exactly what you get from the others.
Then there's Cloudflare. Cloudflare doesn't give you Node at all. This can confuse people because it's running on V8. People hear "V8" and think you can run Node on Cloudflare. That's not how this works.
00:15:36 - Anthony Campolo
They took the thing Node is built with and then built another thing. That's why you can write JavaScript that's agnostic to any of that stuff if you want to use something like Cloudflare Workers. There are a lot of layers to this, and it's baked into the progression of JavaScript, Node, ESM, and all that. It's interesting and very confusing for people.
00:16:09 - Josh Proto
I think it's really interesting what you were talking about. Maybe I'm not fully understanding, but the phrase I'm hearing a lot is being able to write your code in a language-agnostic way and get it to work with your system. I see that as a trend that's being talked about more. That said, I'm operating in a space where that generally isn't as much of an option, at least with the number of clients we're working with at Serverless Guru. We don't necessarily have those options, even though it would be nice.
I'm wondering what challenges you're seeing with how that actually breaks down.
00:17:04 - Josh Proto
Is there a point where, under the hood, it breaks? That sounds fantastic. I wish I could do that. I hope to travel again one day, and if I could do that in real life, that would be amazing. But I can't speak into Google Translate in front of people and then show them my phone. They'll think I'm weird. There's a disconnect there. Under the hood, what are the challenges in doing something like that?
00:17:32 - Anthony Campolo
I can tell you specifically where it breaks. It breaks at Apollo Server. Apollo Server Lambda is where the functions API is being deployed. Traditionally, it gets deployed on Netlify. Netlify is running your Lambdas under the hood; they call them Netlify Functions. Netlify Functions are Lambdas, for anyone who doesn't know. You can't plug and play that with Azure. I know this because I'm working with Thomas, a Microsoft employee, on this right now.
We are having to extract out Apollo Server. There's a very interesting project called GraphQL Helix from The Guild that may have an integration with Redwood support, where you can make the server swappable. We made Apollo Client swappable back in January, and this allowed us to have a React Query provider. For people who don't know the front-end React stuff, React Query is a data-fetching library for React.
00:18:45 - Anthony Campolo
It handles hitting an endpoint, doing a query, getting data back, and handling all the cache stuff that goes along with it. It's by Tanner Linsley, and it's massively popular right now in the React world. Apollo Client is how we handle the stuff that React Query does. Then you have to figure out how you want to handle the GraphQL calls themselves.
You use React Query with GraphQL Request, which is a lightweight GraphQL client. You put them together and then you swap out Apollo for that. Redwood has now decoupled the Apollo Client. We're getting close to doing the same thing with the server. That should allow us to plug and play into different deploy targets in a simpler way, so we don't have to rewrite the API for every single deploy target.
00:19:40 - Josh Proto
That would be no bueno. In a world of infinite time, it could be fun, but what's the timeline for this on the roadmap? It seems very helpful.
00:19:53 - Anthony Campolo
Right now the Azure stuff, and further out the Cloudflare stuff, is not on the V1 roadmap. This is self-directed work because I find it interesting and I know people who can help with it. It requires expertise on both ends to make it work.
The Render stuff is what people should really be looking at because that is shipped and good to go. It's going to be one of the best ways to deploy these apps. Render is like a Heroku for people who haven't used it. You also get nice front-end Netlify static hosting type stuff as well. It's full stack. You get all the stuff you want, and you can build your whole project together. The problem in the past was deploying the front end on something like Netlify or Vercel and then grabbing a database environment variable from somewhere like Heroku or Railway.
00:20:54 - Anthony Campolo
On Render, you can actually host the full-stack app there. It's the ultimate vendor lock-in, but if you're okay with going all in on one platform, it's a really nice integrated experience. Your code doesn't have to change at all. Once you figure out the build process, you don't have to rewrite the API. Different hosting providers just have ways of building your assets and sending them so they can get onto the internet.
There's a weird translation because they'll do it a little differently, and all the frameworks do it a little differently also. Everyone is trying to align on how we want to do this and what's the best way to do it.
00:21:45 - Anthony Campolo
There's so much happening around there. For us, V1 is about making sure the framework itself is solid, which means full TypeScript support and accessibility features baked in. We recently added things like the root announcement, and Dom's work on that has been great. It's really cool to see the pieces of the framework come together.
There's going to be a big push for a more integrated tooling experience, like a VS Code plugin. We'll have really nice deploy targets and features in the framework and get it stable before V1. That's pretty much where we're at right now and hopefully going to be soon.
00:22:41 - Josh Proto
I'd love to hear a little bit about the accessibility features or accessibility issues and Redwood's approach to solving for that. Accessibility is an important thing to design for. True accessibility means 100% of people can use it. Sometimes you see people ask whether we should design for a small percentage of the population, but that's not how it works. I'm interested in how the project approaches this complicated, difficult topic. Even the Microsofts and Googles of the world spend a lot of time and money thinking about it.
00:23:37 - Anthony Campolo
Anyone who says you don't need to think about this is not legally on good footing, or morally, in my opinion. It's not something you can choose to ignore. This has been a huge priority for Redwood. Credit to Dominic "Dom" Saadi, who has really spearheaded this work. We did a whole stream with Ben Myers on the Semantics stream, and we walked through what we did.
It's about the router and how single-page applications work at a fundamental level. If you don't know the difference between an old-school server-rendered thing versus a current JavaScript thing, the main question is where the code lives. If all the code lives on the server, like Rails, you generate a whole bunch of HTML and throw it over the wire. With something like Redwood or other SPAs, you have a bundle of JavaScript that is the logic and the website itself.
00:24:44 - Anthony Campolo
You open that up and as you click links, you're not sending another request back to the server to get a new page. With single-page applications, you get a bundle, and when you click links, JavaScript is executed in your browser to navigate. That breaks a lot of assumptions of how the web works and how screen readers need to interpret what your site is doing. The problem comes down to something simple: when you click a link, the screen reader doesn't know you've navigated away, so it can't announce it.
If you want to go to your contact page and you hit contact, a screen reader would normally announce that page. Because you can't see it, you're listening to it.
00:25:37 - Anthony Campolo
We had to hack it into Redwood so it looks at the page, finds an H1, makes that the title, and then announces it. It's a root announcement component. This was based on work from the Gatsby team and Marcy Sutton, who had been researching how to make Gatsby's router accessible. It's a very niche, deep technical problem. That's why we want to solve it at the framework level.
Having every developer figure out how to do this themselves doesn't make sense. Because we have opinions, we can bake in accessible opinions. That's a huge win for everybody.
00:26:31 - Josh Proto
One billion percent. I agree with that last statement. Good on you and the whole team. You have my stamp of approval for looking at the research and solving a real need through software and technology. If we're not doing good things with the technology we have, we're missing a chance to do more. We could be helping 100% if we think about it. We're going to be working hard and it's going to be challenging anyway, so it might as well benefit the most people. That's very interesting.
00:27:19 - Anthony Campolo
There's a lot to dig into there in terms of how you think about accessibility and whether you're accessible or not. Going back to the Semantics stream, he was on FSJam just a couple days ago. We had a whole episode about accessibility and talked about this in depth. There are downstream effects from designing for accessibility that are good for everyone.
He stressed something I really appreciate: you can't decenter the disabled person's experience. That is the point of making things accessible. It requires dialog with people who use these technologies and using them yourself to understand how they work and the implications of your software when these technologies are being used.
00:28:19 - Josh Proto
I have a colleague I've done some nonprofit work with. They sat down and said, "Josh, this is what it's like for me to be with my screen reader." They showed me the difference between a decent website and a really terrible version of a website. It was shocking to experience firsthand.
They said about 70 to 80% of their experience is the bad experience when they're trying to do things, but they've learned to cope with it. Like you mentioned, centering that experience is the benchmark. I definitely want to listen to that podcast.
00:29:08 - Josh Proto
If you have that benchmark, then I can understand how you're able to hit those marks and make good design decisions based on your customer avatar or your user story. You're getting deep into the demographic and psychographic lived experience of those individuals. Ultimately you're going to make a better product or a better application. It's a win-win.
People need to think about it long enough to discover that it's the right choice. In the consulting world, one thing I'm always listening to our consultants talk about with clients is their end goal. We want to make sure clients have a good understanding, especially if they're coming to us and saying they're on Lotus servers and want to go serverless, or they have no experience and need to do this lift.
00:30:08 - Josh Proto
What should our milestones be, and how are we measuring success? Thankfully, there's a lot of great talent on our team and we know so much about serverless, so those things are often self-evident once we start developing. If the skill set is there, you see results quickly because the fundamentals are better than the last system, ideally. You're going to have a better product. But having a strong North Star vision is essential to the success of these things.
It sounds like Redwood is developing with that, which is really exciting. I can't think of many other frameworks or programs that are featuring it that way.
00:30:51 - Anthony Campolo
Totally. Something else we can get into is meta frameworks. We talked about them last time. We're using that term for things like Redwood because Redwood is built on React. There are AWS meta frameworks, too. That's why you understood what a meta framework was, because you use the Serverless Framework. It's a framework. It's a different kind of framework, but it's the same idea.
I've been playing around with a lot of these things, mainly CDK and SAM, the Serverless Application Model and the Cloud Development Kit. I find it interesting that these two could potentially merge into a super tool. They're starting to integrate with each other, and I think that's really cool, because that's not something that Redwood and Blitz could do. I'm very into these different projects collaborating, communicating, and talking about this stuff.
00:31:46 - Anthony Campolo
There's really no way to make those two things work together because it defeats the whole purpose. What's cool about SAM and CDK is that you get a really nice integration with the infra itself because you get CloudFormation handled under the hood. Redwood has run into a lot of problems because we haven't had a deterministic build. We've had this crazy Yarn monorepo setup with different package.json files for your app and your API, and you have to figure out how you copy both of those and build them. It's a huge, ridiculous pain.
Having all this set up with your code makes it easier. So I'm looking at different options now, with Amplify being another one. I find that each comes at it from a different angle because CDK is code-first. You write code in JavaScript, Python, or TypeScript.
00:32:45 - Anthony Campolo
That's the way you think about your application: code-first and imperative. SAM is from the infra layer. Instead of starting from code, you're starting from YAML. Your configuration is declarative instead of imperative. Both are still deploying full-stack things with code. It's about where you're writing that code, where you're centering it, and how you want to structure it. Amplify thinks about it from the app level: what's your auth, what's your storage, that kind of stuff.
That's why there are three of these things in there. They're meant to give you a single integrated experience on AWS, but they all have a different idea of how you should do that and what you should optimize around.
00:33:43 - Anthony Campolo
I've been building small proofs of concept for all those. It's a great way to get into CloudFormation because it generates CloudFormation for you and lets you write a nicer syntax that makes sense. You can look at it and think, "Okay, I get it," and then rinse and repeat. Before you know it, you're reading CloudFormation like you're reading it.
00:34:09 - Josh Proto
Absolutely. One benefit of those tools is that they let you familiarize yourself with a theory of best practice around how to write this thing. That's always a huge challenge, especially if you're trying to roll out those skills at a team level. Everyone has different levels of familiarity.
If you're able to work off a common style of doing something, you're going to go a lot faster, and you're not trying to mix preferences between team members or mix idiosyncrasies that may not make sense down the line. Especially if that whole team of two people decides to leave the company and then you're stuck with something that wasn't written in a standard way.
00:34:58 - Josh Proto
That's a problem we definitely want to avoid. In different conversations I've had with people in the serverless space and at the framework level, I think we're moving toward figuring out what best practices we want to promote in the industry and setting, "This is this version of writing."
00:35:29 - Anthony Campolo
I'm very curious to ask you: Someone comes to you and says, "I'm building a stack on AWS. How do I build that? Should I use the Serverless Framework? Should I use SAM? Should I roll it all myself?" How would you think about that blanket question?
00:35:46 - Josh Proto
That can be a challenging question. In the past, and currently, nine times out of ten we are most likely going to say the Serverless Framework is the way to go. One thing we like about it is the third-party ecosystem: the plugins and support around that. We're able to leverage everyone else's work for our use cases.
There are certain fringe cases in languages that aren't as supported. There might be hard requirements from the client where everything is in C# or Java. Then it's not all things being equal, and you have to ask who has the best support for those use cases.
00:36:43 - Josh Proto
At those times, we might say use SAM or something else. There's more competition now, and there are a lot of really great ways to handle deployment, which maybe wasn't the case or wasn't something I was as familiar with.
Whether it's Serverless Framework, ARC, SAM, or CDK, there are options. I remember we did a poll on Talking Serverless about which frameworks people like to use. Serverless Framework was big, but ARC was high up there for a lot of people.
00:37:26 - Anthony Campolo
Shout out to ARC. ARC is really cool. I've messed around a little bit with ARC and Begin. For me, I want to take Begin out of the question and play more with just ARC because it's going back to abstractions on CloudFormation. That's as abstract as it's going to get. It's like, "I want to make CloudFormation like six words." That's a really cool idea.
00:37:45 - Josh Proto
I think it's really innovative and really cool. I'm excited to see what happens. If people don't know about it, they should check it out.
A question we've been getting more from the consulting side is around partners and partnerships, trying to figure out how to decide to use one service versus another. As a consultancy, we have to do what's in the client's best interest. That's what we're always trying to do, and we try to give the best understanding of their end goal, both the business goal and the departmental team goals. Those are related, but they're measured differently.
We want to make sure we're giving them a solution that can best get them there with as few roadblocks as possible.
00:38:40 - Josh Proto
There are situations where there may be very niche tools, but for the speed we need to move, or the speed we need to move safely, we can't use the newest thing. It might work in one instance, but can we guarantee it will be around in ten years like Amazon? Probably AWS. Google and Azure are going to be around in some way, shape, or form because companies are making 10 to 30 year decisions. They're not as able to pivot from that.
We take all those things into account when recommending training a whole team on SAM or training a whole team on the Serverless Framework.
00:39:25 - Anthony Campolo
You want to train your team in enough at the base layer to use any of those frameworks because most of them are doing the same thing at the end of the day. Once you understand the infra underneath and you've gone through the pain of clicking around an AWS dashboard to set it up, and then have someone give you a line of code and say, "Here it is," you run a command and you're sold. Then you have to look at how long this thing has been around, how stable it will be, and how similar or different it is from other things around it.
00:40:15 - Anthony Campolo
There's also the question of who is inheriting this app and where they're coming from. What tools would make the most sense for them, especially as we get into a world where you can write any language you want in these things? We're at the point now where most serverless runtimes have really good support for JavaScript and Python. Those are the first two. Then you get Ruby and PHP, then Java and .NET and Go. With things like WebAssembly, you'll eventually be able to write anything you want everywhere. I don't think that's super close, but that's where it's going.
That brings back questions of polyglot programming, microservice sprawl, and all that different stuff.
00:41:11 - Anthony Campolo
Coming from conventions, I like having opinions. Those are good things. You have to be aware of the different sets of opinions available to you so you can weigh them against each other. If you decide you need to build your own thing, you can do that, but you can't do that until you evaluate the other options first.
00:41:34 - Josh Proto
Absolutely. If you understand the bias or assumptions baked into decisions at the front end and have that documented so everyone knows, it helps a lot. I've been sent documents where someone says, "We need to use SAM." Everyone agrees after five lines of conversation. Someone asks, "Why do we use SAM?" And it's just, "Because it's the best." That's the reason. Who knows why that person thought it was the right decision?
Maybe it was or wasn't, but having the paper trail of ideas helps people down the line. It's like, "Why did we decide to use this Java Lambda?" "Because we gave this project to the Java developer and they made it work." But everything else is in Python. It's good to have those solid foundations.
00:42:31 - Josh Proto
Another thing on the topic of teaching and educating teams: I saw on your Twitter profile you added "Lambda School dropout." Serverless Guru has been contemplating the state of serverless education and educating the next generation of technology builders. I'd love to get your thoughts on that.
I remember seeing a headline several years ago, maybe last year before coronavirus or a little bit before that, that said there's a developer bubble from all these code schools and they'll never be able to find jobs, so you should never go to code school again. Now there's a hiring recession, at least according to LinkedIn, and there aren't enough people who have the technical skills to do these jobs. So I'm wondering, what's the state of technology-builder education? Is there a future for code schools? Is there a code school model you think will be the best? I'm interested in your thoughts.
00:44:00 - Anthony Campolo
The Lambda School dropout thing is my attempt to capture nuance. In one sense, it's an endorsement of Lambda because I'm saying, "Hey, I went to Lambda." I'm branding myself along with Lambda. But it's also, "Why'd you drop out? This school is so great. Shouldn't you have graduated?"
There is no simple answer to whether it's a quote-unquote good bootcamp in terms of whether you'll definitely get a job. You can ask if it's a good bootcamp in terms of curriculum, how assignments are structured, and what the payment structure is like. You have to ask those questions first of all. Lambda has been in the news recently for people who follow niche Silicon Valley news because of a round of layoffs. A lot of people have been asking me to comment on it.
00:44:53 - Anthony Campolo
I think it comes down to the churn inherent to what they're trying to do. They're offering a platform for anyone to come in and show up on day one and start without paying a single dollar, and they don't give you any money either. It's a crazy thing that something like that can exist and people can have access to it. That's great, but it's hard. It's not aligned with how we usually think about this stuff.
Teaching people to code is really hard and requires a lot of time and a certain kind of personality. Anyone who wants to put in the time and effort can. The problem is most people get into it not really knowing what it's going to be. They just think computers are cool and it's going to pay super well, and they don't necessarily get the best information about these programs beforehand.
00:45:51 - Anthony Campolo
That's why I try to capture the nuance. For me, going to Lambda was a positive thing. It helped me get to where I needed to be to contribute to Redwood. Lambda didn't really get me a job; Redwood got me a job. The reason that happened is because I essentially dropped out of Lambda to do Redwood instead. I ran away and joined the circus. At the time, you can't say whether it was a good decision or not until it had already worked out months down the line.
You want to talk to students who've actually gone to the school and people who have taught at the school if you want a take on this. Dustin Myers was one of my teachers who had been laid off in this round. He was bummed out, but he left saying his experience at Lambda had been great and that Lambda was doing amazing work and that he was fully in support of what they're still doing.
00:46:44 - Anthony Campolo
I think that speaks a lot to Lambda and what they've built and the amount of people they have helped. In Redwood, we interact with people from Lambda all the time. They hack on stuff with Redwood. That's super cool.
Lambda's awesome. Don't trust really bad media hit pieces written about them. They're not perfect. Getting back to why I think layoffs happen, I think it's because there's a lot of churn in the program. They try new programs. Sometimes they don't really work, so they get rid of them and try newer programs. They're trying a newer program that could be amazing. It's going to be a more backend-heavy, AWS/DevOps-heavy integrated program where they're going to learn how to work with AWS. That could be incredible.
It's hard because they also have so much funding. There's millions and millions and millions of dollars. There's a lot of activity happening around it.
00:47:35 - Anthony Campolo
It's hard to get a handle on it. One of my good friends is going there right now, someone I knew back when we were both music majors together. He asked me about my experience and if I think he should do Lambda. It was about two months ago, and I said yes, based on your experience, I think you would thrive in it. He's been having a ball. He's doing great. He's having a ton of fun. That's my general take on it.
00:48:03 - Josh Proto
Completely. With all education, there's some truth to the axiom that you get what you put in. Across all industries, having a low barrier to entry is fantastic because it makes it accessible to whole groups of people that would never be able to access it. That's fantastic. Having some barriers, whether it's submitting previous work or having applications, can create a more intentional applicant. Not more skilled, but more certain that this is exactly what they want to get into.
00:48:48 - Anthony Campolo
What a process. This is actually important. You should not go to a bootcamp that doesn't have some sort of vetting process where you have to do exercises with JavaScript or whatever beforehand. If they let anyone join, that's not good because you need to give someone at least some idea of what they're actually going to be doing.
Lambda did this, and most bootcamps do, where they have you build a simple HTML and CSS site and then do some JavaScript examples that you have to run tests against. It's just like, write a function, stuff like that. That's the base: do you actually want to do this? If you can't do that, you don't want to do a code school. There has to be at least something like that. But in terms of it being open to everyone and accessible to everyone, that's the thing.
00:49:34 - Josh Proto
I need to look at this new program because I like the idea of an integrated process with AWS. I remember a long time ago being given advice because my partner went to code school and Ryan went to code school as well. I'm around an ecosystem of people who are very successful in their tech careers because of going to code school and bootcamps rather than having a four-year CS degree and a two-year master's degree. That isn't as much my experience. It's great to see more potential for using and learning very modern tools because you can do so many innovative things with a knowledge of the AWS ecosystem.
00:50:20 - Josh Proto
I've also been having more conversations with organizations and communities that organize events around teaching students either in code school or out of code school. Serverless Guru recently had their first real official cohort of serverless interns. Who knows when it was? I think it was before the end of 2020. Time is still blurring together for me.
We got really good feedback. They enjoyed how we weren't holding their hands. We made them look at problems, figure out a solution, and then guided them around building it and learning by doing. That experience made them very successful and very fulfilled right after a more traditional code school experience.
00:51:12 - Anthony Campolo
This is great that you mentioned this, because there's this company, Mapping, whose founders I've been good friends with for a while now via Redwood. They do hackathons, which they also call learning hacks. The idea is that people who are right out of code school and still trying to get jobs can continue to build on those skills. They also work with people who are building these things, get guidance on their projects, and work with the tech.
You get good feedback on whether your docs make sense and whether your CLI actually works. It's huge, and the feedback loop you get from that is incredible. Shout out to them. They're really amazing and doing that exact kind of work.
00:51:57 - Josh Proto
Mapping has been on our radar, and I think we're really interested in learning more about what they do because it seems very unique. Awesome that you brought that up.
Now, I know we're cresting up to the limit of our time. I don't want to keep you forever. I know you're probably doing eight different podcasts today, and you have to let the voice rest a bit. Is there anything else you want to touch on? I know we've painted a great, broad stroke of the various topics we've been talking about today.
00:52:32 - Anthony Campolo
If you're looking for the Redwood stuff, that should be in our last episode. redwoodjs.com has got everything you'll ever need there. Then I'll point people to stepzen.com. That's where you can find us and what we're doing. FSJam is my podcast as well. There's the React Podcast Discord, and the Open Source Discord. Those are two other things that are open source, not in the sense of something like Redwood where it's a huge project, more like a bunch of friends getting together and building something for fun and to hack on something and build their skills, and maybe one day have it be something super awesome.
We've been learning a lot, like GitHub Actions and stuff like that. Events.dev is where you can find a lot of that.
00:53:24 - Anthony Campolo
That should be all the main stuff. Thanks for having me, Josh. I always really enjoy our conversations. You are so similar to me in how you think about this kind of stuff, but you're in the serverless world, which is great because we're kind of built on top of it with things like Redwood, even if we're not entirely integrated with it.
There are so many interesting things happening with these types of frameworks and how they're going to be deployed and stitched together with these platforms. The more people can talk to each other, collaborate, and wrap our minds around what this stuff even is, the better.
00:54:03 - Josh Proto
Absolutely. We're on the outer edge of the things that are getting built, tested, and created with all this. It's always exciting to talk to someone who's also in the space and spending so much time niched into a specific spot.
I was listening to your podcast. The last one I listened to was "To Fork or Not to Fork." I found that really interesting because I'm not pushing a ton of code as much as I used to. So it's like, oh, if there are forks, maybe it means the project's not so good. Context matters.
00:54:39 - Anthony Campolo
The context there is that it's not just any fork. We're talking about Blitz forking Next.js. We're talking about forking the most popular React framework. That's like when Node forked. It's a really big deal. It's like Ethereum forking.
00:54:50 - Josh Proto
Yeah, that is intense. I've been going down my own rabbit holes around chains and smart contracts. Is this a soft fork, a hard fork, x, y, z? Maybe we'll spend some more time and come back in several months.
00:55:05 - Anthony Campolo
To talk about some of that.
00:55:07 - Josh Proto
Potentially. I'll have us wrap up here. We'll end on a cliffhanger. Thank you so much, Anthony, again. And thank you so much to all the listeners of the Talking Serverless Podcast. I hope you enjoyed the listen. If you want to follow up, you can see all the information from these different websites as well as Anthony's handle in the show notes. Have a fantastic rest of your day.