Anthony Campolo - Redwood and StepZen

Episode Description

Anthony Campolo returns to discuss developer advocacy, evaluating tech tools, Redwood's deployment evolution, meta frameworks, and bridging JavaScript and backend ecosystems.

Episode Summary

Sean Washington welcomes back Anthony Campolo, now a developer advocate for StepZen and Redwood core team member, for a wide-ranging conversation about staying current in the JavaScript ecosystem. Anthony shares his approach to evaluating new tools by looking at both quantitative metrics like GitHub stars and qualitative factors like documentation quality and community friendliness, then building minimal Hello World projects to compare frameworks side by side. The discussion moves into what developer advocacy actually entails, with Anthony framing it as education rather than marketing, emphasizing the feedback loop between building tools, explaining them, and talking to the people who use them. A significant portion of the episode traces Redwood's deployment evolution through multiple phases—from Netlify-only to AWS Lambda to server-based PM2 setups to the newer Render integration that handles frontend, backend, and database together. The conversation broadens into React meta frameworks, explaining how projects like Next, Gatsby, Redwood, and Blitz build full-featured development experiences on top of React's view layer, each making different opinionated choices about databases, GraphQL, and deployment. Anthony draws an analogy to music genres, arguing that cross-pollinating knowledge between communities—whether JavaScript frameworks, backend MVC tools, or even musical styles—leads to deeper understanding and creativity. The episode closes with a look at StepZen's role as a managed GraphQL API gateway that consolidates multiple backends into a single schema, and hints at Redwood's potential shift from Apollo Server to GraphQL Helix and Envelope for improved portability.

Chapters

00:00:00 - Introductions and Staying Current in Tech

Sean welcomes Anthony Campolo back to the show, noting his new role as a developer advocate for StepZen alongside his continued work on the Redwood core team. Anthony explains how years of listening to tech podcasts have helped him track trends and develop quick mental models of new projects without needing to become an expert in each one.

The conversation turns to Anthony's deliberate approach to deciding what to learn. He describes evaluating projects through a mix of quantitative signals like GitHub stars and Discord membership alongside intangible factors such as documentation quality and community warmth. He argues that once you assess the full picture, it becomes clear which projects stand above the rest, and understanding the landscape within your niche helps you spot opportunities for collaboration and integration.

00:04:30 - Building Hello World Projects as a Learning Strategy

Anthony outlines his practical method for learning new tools: distill each one down to the simplest possible Hello World that still represents a realistic use case. He walks through how he systematically creates getting-started tutorials for React meta frameworks and build tools alike, following official docs and then improving on them by filling in gaps and documenting friction points.

This approach also creates a built-in comparison framework. By building minimal projects with consistent steps—project creation, dependency management, conventions, and deployment—Anthony can directly map one tool against another. Sean adds that writing these tutorials reinforces learning and creates reference material, and Anthony notes that most technical content creators write primarily for their own benefit, with community value as a welcome side effect.

00:07:32 - Developer Advocacy and the DevRel Landscape

The discussion shifts to Anthony's new developer advocate role at StepZen. Sean asks what the title actually means, and Anthony breaks down DevRel as an umbrella covering advocates, community managers, and technical content creators. He emphasizes that effective advocacy requires building with the tools, explaining them clearly, and actively talking to users to close the feedback loop.

Anthony addresses the recurring question of whether DevRel is a marketing function, arguing that education is a prerequisite for adoption rather than a sales tactic. He stresses the importance of empathy in developer tooling—understanding what developers actually need rather than projecting your own preferences—and explains how open source communities provide the essential feedback that keeps tool development grounded in real-world usage.

00:12:14 - Redwood's Deployment Evolution and the Road to V1

Anthony provides a detailed update on Redwood's progress, explaining the delayed V1 release due to scope expansion around TypeScript support and end-to-end testing with Cypress. He then traces the framework's deployment history through distinct phases: starting with Netlify and its Lambda-based functions, expanding to raw AWS Lambda via the Serverless Framework, adding traditional server support through PM2, and arriving at Render's integrated solution for frontend, backend, and database.

Sean finds the Render integration particularly compelling for developers who prefer working with Postgres directly. The conversation explores how each hosting provider has its own configuration format and build process, and how Redwood's CLI commands abstract away provider-specific complexity. Anthony highlights that the simplicity users experience comes from extensive work by the Redwood team to figure out portability challenges across providers, including the subtle but consequential differences between services like AWS Lambda and Azure Functions.

00:25:06 - Understanding React Meta Frameworks

Anthony defines meta frameworks as tools built on top of JavaScript UI libraries like React, Vue, or Svelte, using Gatsby, Next, Redwood, and Blitz as canonical React examples alongside Vue's Nuxt and Svelte's SvelteKit. He explains that React was designed as just the view layer, which naturally led to more opinionated frameworks emerging on top to provide fuller development experiences with routing, data fetching, and backend conventions.

Sean connects this to his experience with traditional MVC frameworks like Rails and Phoenix, where the backend patterns felt comfortable but the view layer was always a struggle. With React meta frameworks, the relationship flips: the view layer is familiar, and the choices around databases, GraphQL versus REST, and deployment become the differentiating factors. Anthony notes that while static asset deployment is largely a solved problem, database portability remains genuinely complex, pointing to Prisma's year-long effort to support MongoDB alongside Postgres.

00:33:55 - Cross-Pollinating Ideas Across Communities and Genres

The conversation broadens as Anthony advocates for paying attention across different technology communities rather than staying siloed. He draws parallels between JavaScript frameworks and backend MVC tools, noting how LiveView, Livewire, and Hotwire represent the same innovation rippling across Phoenix, Laravel, and Rails. Understanding these parallel developments provides a more complete picture of where full-stack development is heading.

Anthony extends this philosophy with a music analogy, comparing genre loyalty in music to framework loyalty in tech. Just as learning jazz improvisation can transform a rock performance, cross-pollinating ideas between technology communities leads to creative breakthroughs. Sean builds on this by discussing how tracing musical influences backward reveals shared roots, much like how studying framework histories reveals common architectural patterns and borrowed innovations.

00:44:25 - SvelteKit, Svelte, and Watching a Framework Grow

Anthony identifies SvelteKit as his favorite recent discovery, sharing that he was present when it launched and published one of the earliest blog posts about it. He describes how SvelteKit shares Redwood's serverless-first philosophy while also incorporating modern build tools, having switched from Snowpack to Vite. Watching these decisions unfold in the open helped deepen his understanding of the broader tooling ecosystem.

The discussion touches on Svelte's appeal as a framework that offers React and Vue-like capabilities with a more concise syntax and smaller bundle sizes. Anthony argues that while Svelte's smaller community is a current limitation, its advantages in developer experience and shipped code size suggest that something like it will eventually challenge the incumbents. He notes how trends often appear first in smaller communities before reaching mainstream adoption, reinforcing the value of watching across ecosystems.

00:47:04 - StepZen, GraphQL Gateways, and Redwood's Backend Future

Anthony explains how he's connecting his work at StepZen with Redwood by building example projects that use StepZen as a managed GraphQL API gateway. StepZen consolidates multiple backends—like Shopify, Airtable, and other headless services—into a single GraphQL schema, and Redwood's existing architecture for making authenticated GraphQL requests from serverless functions turns out to be a natural fit for this integration pattern.

The episode closes with Anthony previewing a potentially significant change in Redwood's backend: replacing Apollo Server with GraphQL Helix and Envelope from The Guild. He explains that Apollo Server's Lambda-specific packaging creates portability issues across deployment targets, and Helix is designed to be more plug-and-play across environments. While the technology is still very new and lightly documented, Anthony flags it as something worth watching for anyone invested in the GraphQL and Redwood ecosystem.

00:57:19 - Wrapping Up

Sean thanks Anthony for the conversation and acknowledges how much he personally benefits from Anthony's habit of sharing links and engaging publicly on Twitter and in the community Discord. Anthony expresses gratitude for being part of the community and the opportunity to keep coming back on the show.

The two agree to schedule another episode to go deeper into the technical specifics they touched on, particularly around GraphQL tooling and Redwood's evolving backend architecture. The episode ends on a lighthearted note, with Anthony joking about eventual burnout while clearly still energized by the breadth of work he's juggling across StepZen, Redwood, and content creation.

Transcript

00:00:08 - Sean Washington

I think we're good to go. So, everybody, we're welcoming back to the show this week Anthony Campolo, who is already doing many things, but it seems like the things they've been doing have increased since last time.

As far as I'm aware, you're a Redwood core team member, you've got the podcast, and since we last talked, you are now a developer advocate for StepZen.

00:00:32 - Anthony Campolo

Yeah, that's been the biggest change since we last spoke. And it was very much connected to the work I've been doing on Redwood, because it's a GraphQL company, specifically for managed GraphQL API gateways, which is a lot to unpack, but we can get into that a little bit more as we go.

00:00:51 - Sean Washington

Managed GraphQL API gateways. Yeah, I'm sure. We'll circle around to some of that stuff too.

But basically, we've seen you hanging around the Discord and you're always kind of dropping links. It seems like whenever we're talking about something that's sort of front end related or tooling related, you know something about it.

00:01:13 - Anthony Campolo

Yeah. I try to keep my ear to the ground as much as I can. A lot of this I can owe to being so into podcasts and having listened to a lot of tech podcasts over many years, because eventually you start to see the trends and you can see projects develop over time.

If you see a project that people have been talking about for a year, it's not really going to take you that long to learn at least a one-liner explanation of it. People can get very wrapped up, like, "There's so much stuff I have to learn." Just take it in little bits and try to at least say, "What is this thing first off?"

Even that, just being able to say what a thing is, is usually useful for people because they hear all these terms and it's hard to wrap their mind around it. I just enjoy being in the conversation, hearing the conversation.

00:02:01 - Anthony Campolo

So I always try to stay aware of what's happening and then do my own research to figure out where I want to place my bets in terms of what I want to learn, what I want to invest in, and what I want to recommend to other people who respect my opinion on these types of things.

00:02:19 - Sean Washington

Yeah, that's interesting. So you actively think about what you should learn, what you should invest your time in, and things like that. Do you have any sort of criteria that you follow for those, or is it more of a gut feeling?

00:02:33 - Anthony Campolo

You can make it measurable if you want to. For me, it's kind of a holistic thing where there's the bare numbers, like Twitter stars, sorry, GitHub stars, Twitter followers, YouTube subscribers, members of a Discord. There are lots of numbers and ways of measuring a community that are actually fairly objective once you take them in aggregate.

Then you also have the intangibles, like how well written the docs are, and even more intangible, how nice people are when others come in to ask questions or contribute. You want to look at that whole thing. Once you do, I think you start to see which projects are a step above most in terms of having all of that, because it requires a whole team of people with various skill sets to do that well. And once you do it, usually other people will start paying attention to it.

Eventually you become aware of all the interesting projects that are happening within a specific niche. There are a million projects in blockchain, all this stuff I don't know anything about.

00:03:36 - Anthony Campolo

So within my own realm of front end JavaScript, eventually you'll get a handle on who the interesting projects are, who is working on them, and what their goals are for where they're trying to take it. Then you can think about, okay, how do we integrate these things? How do we collaborate between these different projects?

00:03:53 - Sean Washington

Yeah, it's definitely a lot to take in all the time. I go through cycles where I'm looking around and interested, and cycles where I just can't push through anymore and go back to what I was doing or focusing on. So it's definitely a cyclical thing for me.

Do you try to meter that? Do you have any sort of process for, "Okay, now I feel like I want to go around and find some stuff," or is it something that's always ongoing with your process?

00:04:30 - Anthony Campolo

Yeah, I would say I try to cover what I think is the important stuff, the things that are a need-to-know type of thing, and then cover it to the extent you need to know to build a proof of concept.

When I think about what I'm trying to learn or build, it's usually, "How do I get this to a hello world in the simplest way possible, but still have that hello world be a good representation of what a real version would be?" That can usually be condensed down to one really good, well-written blog post.

I'll usually think of the different React meta frameworks, like Gatsby, Next, Redwood, Blitz, Remix, and think, "How do I make one good Hello World tutorial for each of those?" Then I go down the line. That's also what I did for Esbuild, Vite, and Snowpack.

Anyone could do this. All you have to do is go to whatever that project's docs are, go to their Getting Started guide, follow it, and basically copy-paste it, then add all the stuff that hung you up and that made you think, "Okay, they should give me this command. It should give me this flag. I should have explained this part." Then change it a little bit and keep changing it. At the end you should have a better Getting Started guide than whatever they have.

00:05:49 - Sean Washington

Right. So you kind of distill the things that are common amongst all of them, and you start to get a hunch for, oh, this thing lives in this space. You probably need to do A, B, and C. There may be some variances in there, but they're generally the same.

00:06:01 - Anthony Campolo

And it gives you a workflow so you can compare them. So it's like, what are you going to get if you use the default boilerplate of Vite versus Snowpack, and then how would you deploy it with their most basic integrated deployment setup?

You can look at those two tutorials and directly map one to the other because this is what took me from here to here, and this is how it was deployed. The steps are usually: how do you create the project, which can be starting from scratch or generating a boilerplate; how do you get all the dependencies in there; what are the conventions of the thing, like how they map pages or how they talk to the back end; and then how do you deploy it?

I try to cover those chunks of each thing, which usually gives you enough of an idea of what it is and what it would actually be like to work with it without overwhelming you with a whole real version of it, like a production app.

00:06:52 - Anthony Campolo

So it's a way of distilling it down to something that should be comprehensible enough to at least get the point. You're not going to become an expert in these technologies reading my blog posts. You're going to know very little about each of them, but you're at least going to understand what it is and can talk about it, and not feel overwhelmed by all these tools you don't understand.

00:07:12 - Sean Washington

Sure. Yeah, that makes sense. And I guess the act of writing it down, writing the blog post, helps reinforce everything too. It's also material you can go back and reference later as well.

00:07:22 - Anthony Campolo

Yeah. Most people who write this kind of tech content will tell you they do it mostly for themselves. And if it's useful for other people, that's cool. It's a nice bonus.

00:07:32 - Sean Washington

Yeah. Cool. I wanted to circle back real quick to StepZen too. You mentioned developer advocate. I don't exactly know what that is by the book.

I've heard terms like DevRel. I've seen people on Twitter saying they're hiring developer advocates. My non-educated guess would be you're basically advocating for why StepZen is useful or how it could be useful. They have tools that benefit a certain number of people, and you demonstrate why that is.

00:08:07 - Anthony Campolo

Yeah. That's a really good way to describe how I do my dev advocate job. Part of the reason why this is a complicated conversation is that there are many facets to it that can't all be done by one person. So there are a couple of things that are being bundled into it, which is why you have the term DevRel.

I think of DevRel as the overarching thing that includes dev advocates, community managers, technical content creators, and the difference between these roles can be kind of fluid project to project, depending on how big the projects are and what stage they are in their life cycle. Usually you can break it down to building the tools, explaining the tools, and interfacing with people who are using the tools.

That's how I like to think about it because then you want to make sure you understand how the tool works. So you want to work on it a little bit and at least contribute to it.

00:09:04 - Anthony Campolo

Then you want to be able to explain that to people. You want to write some docs for it, and you actually want to talk to people using it, because that's where you're going to learn the most about the thing that you think you already know so much about. You're using it and building with it, but until you go and talk to the people, you don't really know if anything you've done matters at all.

It's too much for one person to do. But if you don't do a little bit of all of it, you can get disconnected from the larger goal. And like you said, there are no books. This is a super new thing. It's kind of what used to be called a technical evangelist, which was a term that Apple invented, I think.

It's shifted a little bit and has really gone into overdrive with Covid because everyone went online. Everything had to be through digital content and through these platforms, and you just had to have people who knew how to do this.

00:10:00 - Sean Washington

Yeah. So to me it sounds more like it's about education and learning how to help steer a thing than just sales.

00:10:09 - Anthony Campolo

That's how I think about it. And it's funny because this is the big elephant in the room. The conversation is the question of: is it a marketing role or not, and should you think about it as a marketing role or not?

I can say I'm not a marketer, but if I was hired to be a marketer, then that's a problem. You have to be aware of what you're actually going to be expected to do and what you really need to do. For me, I don't think you're ever going to get someone to use your thing until they understand it. So for me, getting people to learn a thing is just a prerequisite for it being used.

I don't think of it as marketing in the technical sense, but it contributes to the bottom line in that way.

00:10:54 - Sean Washington

Yeah, that makes sense to me. If a person doesn't understand your thing, why would they choose it if it doesn't make sense, if it's not clear, or if the benefits are unclear? Why would they pick it?

00:11:06 - Anthony Campolo

Mm-hmm. Yeah, totally. And that also involves empathy and understanding. What are people actually building with it? What do they need to build with it?

Because when you're building developer tooling, it's very easy to get wrapped up in your own ideas about what developers want. It's easy to get wrapped up in what you want as a developer, which can lead you astray very quickly. So that's why you need that feedback loop of having people actually use the thing and build real things with it.

That's what you get from open source frameworks, where you have dozens or hundreds or thousands of people building stuff with your thing.

00:11:38 - Sean Washington

Yeah, I found that a lot too. If I'm using VS Code, you'll install a plugin and it's very specialized to whoever wrote it. Maybe I don't work that way or don't like to work that way, but I could always make my own. That's cool. It's open source, but I don't want to.

I think that's part of the reason why I've always felt more comfortable, well, the last couple of years now, using JetBrains stuff because it's all just the same.

00:12:05 - Anthony Campolo

Well, this is why everyone's just going to use VS Code one day, because it's going to integrate with everything and it's going to be so simple. I don't know, we'll see. But yeah, that's...

00:12:14 - Sean Washington

That's hard to argue against. I will resist for as long as I can. No, it sounds cool.

You've been writing a ton of blog posts too. You were talking about your blog earlier, and I've been impressed recently with the amount of content that you're putting out. You're doing your day job with that stuff. We mentioned that you're part of the core team on Redwood too.

I haven't been following Redwood that closely lately. I get the forum digest emails, so I see some conversations happening and I see some of the bigger shifts happening. But what's been going on in the Redwood world in the past several months?

00:12:58 - Anthony Campolo

Yeah, we're trying to make a big push for V1, which, if you've been following Redwood for a while, probably sounds hilarious because we originally said we wanted to get V1 out by the end of last year, and then we said we wanted to get it out by Q1 of this year. If you look at the calendar, we're almost at the end of Q2 already.

Partly that's because over the last couple months so many interesting things were happening with the framework that we kept building new stuff, so you get the scope creep kind of thing. We had to dial it back and say, "All right, basically TypeScript and tests are the big thing now. How do we get full TypeScript support?" We were working on that for a year. We talked about this on the last episode and we're still working on it, but I think we're getting really close.

And then we have a whole end-to-end testing suite now with Cypress for testing the tutorial and things like that.

00:13:51 - Anthony Campolo

So we want to make sure that's really going to be solid for V1. That's why it's taking a really long time. Because we're saying we want this to be a serious framework, we don't want to just put it out because we said we were going to put it out.

That's all super interesting stuff that I'm not really close to because I don't know anything about TypeScript. I can write tests, but I'm not a testing expert by any means. What I've found really interesting, and an area I can fill, is trying to connect the dots for the deployment story.

RedwoodJS was originally proposed and has been this "universal deployment machine," a common term Tom talked about a lot when he was putting it out into the world. The idea is that you want it to be like your front-end Jamstack sites where it syncs to a git repo, you do a git push, it updates the repo, that triggers a build, that triggers the deploy, and then you have it on a link and you just got it.

00:14:52 - Anthony Campolo

That works really well for static front ends right now. We want to get to the point where you can do it with a server and a database too, which is a lot harder to do.

I broke the history of Redwood's hosting down into a couple phases in this blog post I put out recently. The first phase was Netlify. It was designed for Netlify specifically, and it did that with Netlify Functions, which are a wrapper on top of AWS Lambdas. It's basically a Node server. Most people don't think of Lambda this way, but it is.

It was a way to make it really easy for anyone to deploy without having to know AWS or how to do credentials and all the stuff around AWS. But as soon as we got that, people were like, "Okay, but how do I just use it with AWS Lambda?" People immediately want to drop down to the base layer.

00:15:55 - Anthony Campolo

So you had people do it with the Serverless Framework, so you had your infrastructure-as-code kind of thing. That was really great. But then people were like, "Okay, but actually I do want a server."

So people took this thing that was designed for serverless Lambda handlers and just ran it on PM2, just ran Node and did it that way. We talked about this on our first episode as well.

00:16:22 - Sean Washington

I think I was even asking about that, right? Like, what if I just want to put it on a server?

00:16:28 - Anthony Campolo

Yeah, and you can do that. So that was phase two. Phase zero is Netlify. Phase one is AWS Lambda. Phase two is PM2, serverful.

Then phase three was, "Okay, but we still haven't figured out the database yet." So there's still this question of, in all of those scenarios, you still have a database you need to spin up completely separately from your server and then connect it with an environment variable. We wanted to have not only the infrastructure as code with a deterministic build and everything, but to have that for the front end, the back end, and the database.

That's where Render comes into the picture, which is like a combo between Heroku and Netlify. It does a little bit of both and tries to give you a really nice integrated experience. That was something we were talking about, but it hadn't been done yet. That's shipped now and has been for a month or two.

00:17:23 - Anthony Campolo

And it's awesome. It's like the future of dev. It's so cool.

00:17:28 - Sean Washington

That, yeah, I should look into that because that sounds really nice. That's kind of where I would probably live. I think the idea of shipping to Jamstack makes sense for many things, but I just feel comfortable with a Postgres database, knowing Postgres is there and using it. So the idea that it's plug-and-play is really killer.

00:17:53 - Anthony Campolo

And partly it's always just been Postgres, and that's what's allowed us to do this on so many different hosting providers. Everyone has a site. Let's just all use Postgres, which is great.

00:18:03 - Sean Washington

Yeah. That's interesting. You sent me the blog post and I haven't read it yet. I linked it in the chat and I'll put it in the show notes as well.

To me that's really compelling because, like I've been mentioning, I've been hanging around Remix and the Remix Discord. One thing that was really nice is that I don't even know what version it is, like 0.17 or something, but it has deployment plugins for a bunch of different providers, like AWS, like we were talking about earlier. You could put it on Heroku, you could put it on Vercel.

It's nice to be able to say, "Oh, you have a plugin for my preferred platform-as-a-service of choice," and just plug in my credentials and it works. That's really compelling.

00:18:48 - Anthony Campolo

Yeah, it's probably because every one of these providers has some sort of specific TOML or YAML file, like a Netlify TOML, a YAML, or something like that. That is the infrastructure as code.

That's what writing the blog post is really good for me. I went back and was like, "Who has done this, and how did they do it?" Look at their code, how it evolved, and the steps it took to get there.

When I was starting to learn Redwood, I knew a little bit of React and a little bit of back end, like Express and Postgres, because that's what my bootcamp covered. So I had to learn the GraphQL stuff and the deployment stuff because it just worked with Netlify. You could follow the tutorial and you had a completed deployed app at the end, so you didn't have to think about that part at all.

00:19:44 - Anthony Campolo

But seeing the framework go through this process of trying to make it portable basically helped me learn what the difference is between all of these things, and what the difference is between serverless and just running a server. I saw where the rubber met the road with all of these things.

Even Thomas, who everyone probably knows, has been on the show a lot and hangs out in the Discord. He works for Microsoft and has been helping with the porting from Lambda to Azure. People always say, "Oh, Azure Functions are just like Lambdas." They are and they aren't. It's the same idea, but the differences are subtle enough and have large enough consequences that you'd be surprised how hard it can be to actually plug and play this stuff.

00:20:31 - Sean Washington

Yeah. It's not something I want to try to do. I've been really lucky that in my current day job, all the DevOps stuff is not handled by me. So when we're like, "Hey, we need to automate CI for this," someone else just makes it happen. I get to use it, and it's nice.

That's been really nice. Anything in my side projects, I've just been using Railway recently, and it's all there. So I've not done any of this stuff, and it's been great.

00:21:01 - Anthony Campolo

Yeah. Railway's awesome. I think I'm the one who told you about Railway, right?

00:21:05 - Sean Washington

Yeah. You did, you did. Yeah.

00:21:07 - Anthony Campolo

Yeah. There are so many hosting providers like this. Some are just kind of database heavy. Some want to own more of the server and the database, some want to own the whole thing, and some are more focused on containers or serverless.

That's a whole separate thing. We've had people figure out how to run Redwood on Docker, but it's not really documented yet. We don't have a Redwood opinion around how to dockerize even though we know we need one and people are asking for one. That's another side quest on this deployment story.

00:21:41 - Sean Washington

Sure. Yeah, that's cool though. It sounds like it's coming a long way. Back when we talked, not like it was years ago, everything still felt like it had a level of maturity to it, specifically Redwood, because of the level of the documentation and the presentation of the site. It looks great. It reads great. It communicates well.

Even looking at it as we're talking about it, just kind of scrolling through again, I'm remembering things that I liked about it. I think last week or maybe two weeks ago I complained about form abstractions and form libraries, and I had some feedback on that.

Most notably, I was talking about how Remix just uses regular old HTML forms and then they do have a form component that can progressively enhance it. Many people are like, "Well, that's too simplistic."

00:22:33 - Sean Washington

There's a reason why these form abstractions were made in the first place.

00:22:36 - Anthony Campolo

A lot of it's validation helpers and things like that, because there's a lot of really common stuff we do with forms that's not built into the platform. It's not that you can't do it. It just saves you time to have helpers built in with the form libraries.

00:22:50 - Sean Washington

Right? And honestly, one of the nicest things to me at first about Redwood was the form abstraction. It was nice to use.

00:22:59 - Anthony Campolo

Yeah. And that's not even really us. We basically are using React Hook Form and doing a very light abstraction on top. But you can just use React Hook Form by itself, or you can just literally write an HTML form because it's just like React. So you just throw a form component.

We give you three different levels of form abstractions. You can pick whatever you want.

00:23:22 - Sean Washington

Yeah. The abstractions that you did put on it, though, are pretty nice. It just feels really seamless. It feels like you wouldn't be able to tell, unless you were familiar with React Hook Form, that this is React Hook Form. Yeah. That's awesome.

How much work is actually being on the core team for Redwood?

00:23:45 - Anthony Campolo

It's a thing where they're looking for people who are genuinely passionate about it, want to be involved, and are going to stick around. It's not so much about everyone putting in a certain amount of hours, because most people aren't being paid for it. There are some people who are being funded by Tom through Preston-Werner Ventures, and I'm not privy to what types of negotiations go on with that or how much work needs to be done.

Most of the people on the core team do it in their spare time for fun because they're passionate about it, so they contribute what they can. There's never anything expected of you. Usually people commit to things, and if you commit to something, then it's expected of you, but you're never expected to commit to anything. So it's really nice.

For me, before, when I was talking to you, I was still driving for Uber. I used to be working full time as a delivery man while I was going to a coding bootcamp, while I was also applying for jobs, writing blog posts, and going out and talking at things.

00:24:42 - Anthony Campolo

And once I actually had a job, even though I had to spend time doing my job, it cut out all those other things and gave me the mental space to keep coding for an extra hour or two, even after a day of work, because I'm enjoying all the stuff I'm doing.

I'm not killing my body. I'd spend eight hours driving every day. So yeah, I feel like I've been able to be more productive in all the things I do. It's been great.

00:25:06 - Sean Washington

Yeah. I'm super glad to hear that. That's working out that way.

We were talking, you mentioned React meta framework, and I wanted to circle back to that quickly too because I may have mentioned it on a show at some point, but I don't think we've ever defined what a React meta framework is for the audience.

00:25:27 - Anthony Campolo

Yeah. And I would say it's not going to be specific to React. When I use the term meta framework, I'm usually talking about something built on either React, Vue, or Svelte, and you can probably find other ones that map to this as well.

The idea is that those are already things built with JavaScript, either libraries or frameworks. Don't worry about whether it's a library or framework; that's a red herring to this conversation. If you're building on top of one of those things, then you're a meta framework.

Most people know Gatsby and Next as things that are built with React on top of React, so those are canonical examples of meta frameworks. Then you have Redwood and Blitz, and then you have things with Vue, like Nuxt and Gridsome, and then Svelte. A lot of people probably heard about SvelteKit. Some people may have heard of Sapper a little while ago. All of these things are taking the JavaScript UI library because this is the thing.

00:26:25 - Anthony Campolo

React was only the V in MVC. It's just the view. That's why you can't just use it to build your whole thing. It's not supposed to do that.

So it makes sense that people would build these more full-featured frameworks on top of it because they own a certain space and do it really well, but people still want a more full-featured framework that can do stuff fast for them and give them good conventions. That's what we've had for 20 years of doing development, and the way you want to have those opinions is going to differ.

That's why you're always going to end up with so many different things. Do you want GraphQL? Do you not want GraphQL? Do you want to have a database opinion? Once you have a database opinion, do you want to have an opinion about X? So there are different levels of these meta frameworks.

Going back to building a simple proof of concept, with each of them that's all you really need to do to compare these things, because you'll get pretty quickly why Gatsby is different from Redwood.

00:27:20 - Anthony Campolo

There's no Postgres database with Gatsby, you know. You just have to build something with it to understand all the pieces and how they fit together, which pieces you get, and which pieces are just, "Go find that one yourself."

00:27:32 - Sean Washington

Yeah, I've done a little bit of searching around. I've tried out Blitz, I've tried out Remix, I've tried out Next. I've never actually used Gatsby. I haven't had to use it yet. I've used Redwood a little bit.

I like that there's a big common ground, the actual presentation layer, the templating layer, it's just React. So at some level you're always familiar with something coming in.

I think it was last week or two weeks ago I was talking about how I never really felt truly comfortable with Rails ERB templates, embedded Ruby templates, or X templates with Phoenix. But when it came to Vue and React, I pretty much always felt comfortable after the initial learning curve, building UIs with them. So for me with these React meta frameworks, it's like flipping the MVC stuff around, right?

00:28:31 - Sean Washington

When you have Rails or Phoenix, the back end side of it, the MVC side, the M and C side, are comfortable and nice for me to work with. But the V part was always difficult.

With React, once it's flipped around, the V part is easy, and then it's just like you said, making a decision about all the others. I've seen some of these frameworks allowing you to pick and choose, like you said, do you want GraphQL? Do you want REST? Do you want Postgres? Do you want Mongo? Basically providing adaptive layers so you can plug those layers into that system, which seems interesting.

00:29:16 - Anthony Campolo

You're able to do it if you're just shipping static assets. That's the one that is really easy for everyone to align on. Once you get into all the database stuff, that's when it gets really complicated.

Switching between Postgres and Mongo, it's like I've been watching Prisma spend a year figuring out how to do that, and they're just about to get over the finish line. It actually does work. I got a Prisma thing spun up with MongoDB, did a MongoDB Atlas thing, and it works. It's really cool to see that happen.

But deployment providers are where you want to be able to plug and play because everyone has their own opinion of where to host these things. It's a build process, so that's what's going to be different. Your code can stay the same, but how you get those assets to the actual providers is complicated.

00:30:15 - Anthony Campolo

That's where Redwood is very different from something like Next because you have two sides, a website and an API side, and they both have a package.json. There are reasons for that, but it's also really hard to work with.

How the project is set up is going to have huge implications for how well they're going to plug and play with these different providers. So as you're building it, you think about that stuff and get to the point where it's like, "Okay, I need to figure out what I need to do to get them all to work together." Then you start building all the complicated stuff on top.

You really want to think about where you want this to live, where you want to deploy it, and where you may potentially want to deploy it one day, because there are a lot of considerations that go into making these things portable.

00:31:05 - Sean Washington

Yeah. The way so far has been, if you do need to switch or want to experiment with others, you generate a new project and then just copy your app folder over to it, because the project generator will scaffold the different configurations. If you're using Express, it'll be a separate server file. If you're using Vercel, there'll be a separate Vercel config.

It was kind of wild the first time I looked at it. I was like, "Oh, they want me to just make a new project and copy my app folder over." I don't think that's ever been the process for me before when switching to a different provider. But I thought it was clever. It worked. It was clever, but it wouldn't have been something I thought of myself.

00:31:47 - Anthony Campolo

Yeah. And that makes sense because with Redwood, you have a command. You run that once and you're good to deploy to that thing. You'll say yarn redwood deploy netlify, and it creates a Netlify TOML that has the build steps. If you say Vercel instead of Netlify, it does what it needs to do for Vercel.

It doesn't change any of the code. So you can have your app deploy in one thing, then just change the deploy step and deploy it again. You don't need to change any of the actual code in the project.

This is where the universal deployment machine comes in because they all use git. At the end of the day, as long as you're going to attach to a GitHub repo, or GitLab or Bitbucket or whatever adapters you want to build in, it all comes back to these repos.

00:32:35 - Anthony Campolo

That's how we're developing these things, so it makes sense.

00:32:38 - Sean Washington

Yeah. Part of me thinking about changing providers willy-nilly like that would freak me out. A few years ago I'd be like, "No way. There's no way we're going off Heroku over my dead body." Once it's set up, you don't touch it kind of stuff.

So it's kind of wild to be thinking that within a few commands you could realistically do it. I've never tried to do this with a complicated production app myself, but seemingly with the universal deployment machine, you just run a command and now you're taking advantage of a different service for whatever reason. There'd probably be a reason for the switch, not just doing it for fun.

00:33:17 - Anthony Campolo

And the reason why it's simple is because the Redwood team spent the time to figure that out. If you were doing it for your own bespoke app, it would not be simple at all.

00:33:28 - Sean Washington

Yeah, exactly. That's interesting to think about. It's just such a different thing. What's interesting to me is observing the chat.

We have a few people that are doing Phoenix. We have some people doing your regular old monolith apps. And a lot of the time when we're talking about this front end tooling, that's a totally different planet. So it's kind of cool to see people's reactions to some of this stuff.

00:33:55 - Anthony Campolo

Well, at least better discussions that way. When you get only JavaScript people talking or only back end framework people talking, it's just another type of echo chamber.

I'm all about, what are the commonalities between the different things that we're all doing? Because ultimately we're all putting this stuff on the web.

What I've really enjoyed about Remix is that Remix is like, "Let's lean into the web as our conventions themselves." That's super cool.

00:34:26 - Sean Washington

Yeah, that's one. For me, if I'm cranking on side projects and I have limited time outside of my work, depending on my energy levels, I'm not spending 40 hours a week on side projects.

So when you're talking about doing research and picking a tool for a deliberate reason, that's one reason I picked Remix. It's all in MDN. If they're using the Fetch API, like Request, Response, and Headers, it's all in MDN. It's already there. It's existing. I'm using it in my day job too if we're using fetch, so it shares a lot of commonalities with things I'm already crossing day to day.

Yeah, I've been enjoying it so far.

00:35:19 - Sean Washington

So one question I wanted to ask you too is, since you're seeing so much and you're going around looking at these different tools, and you're trying to figure out, "What's the fastest way possible to get to Hello World, and how can I document that?"

Aside from Redwood, what's been one of your favorite tools that you've discovered recently, or at least read about recently?

00:35:41 - Anthony Campolo

Yeah, I've definitely enjoyed getting to use SvelteKit and watch the progression of that one, because it's the only one out of all these where I can say I was actually there the day it was released. They were like, "All right, here it is. Here's the code. Run this command, you can use it."

I wrote a blog post the next day and no one else wrote a blog post for like a month. So I've gotten to see this from the ground level.

I already really wanted to learn Svelte, and I was already going to use Sapper most likely. So it was kind of perfect, where they're like, "You want a Svelte meta framework? We're actually giving you the newest, hippest Svelte meta framework that anyone's building." It came at the right time.

It has similar ideas to Redwood, not in the full stack sense, but in the serverless sense, because it's considered a serverless-first framework.

00:36:36 - Anthony Campolo

We've been talking about serverless-first since Redwood started. So this is something that they branded Svelte with, this serverless thing. And I was like, "Oh, cool. I already get this. That makes perfect sense to me." Whereas some people are still like, "What does that actually mean?" There are lots of buzzwords and stuff that make it hard to wrap your mind around.

But I was like, "Okay, so you're just deploying the site with a Lambda. Cool. I'm totally into that." And it also has all this server-side rendering and hydration stuff. It's using modern build tools. It was originally using Snowpack but then switched to Vite.

So I got to see a lot of these other conversations play out within the framework of SvelteKit, which helps you understand these things. When I was first learning Redwood, learning a little bit about Blitz.js was really useful because they both used Prisma, and I was able to see the commonalities between the two and what they each had to build on top of it to do the rest of the framework.

00:37:37 - Anthony Campolo

It's a similar thing with SvelteKit. Why they picked Snowpack in the first place, then why they switched to Vite. Seeing these conversations is what makes open source so valuable, because the conversations are, for the most part, in the open.

It was kind of weird because they had a lot of it happen on a private repo and then eventually made that repo public. You can now go back and see the conversations, but they weren't public at the time.

That's another question about what it actually is to work in public and what's not, what should be in public and what isn't. It's a bigger meta question around open source.

00:38:13 - Sean Washington

Yeah. Looking at it kind of looks familiar already. Like you're saying, all these things are kind of driving parallel to each other. They're just spaced out a little bit, I guess is the best analogy I can think of.

So it's cool. I've never written a line of Svelte in my life, but it looks familiar, which is kind of cool.

00:38:36 - Anthony Campolo

Yeah, it seems fun. Svelte is meant to give you the same kind of powers you would get from React and Vue, but with a more concise and simple syntax. It's also built in a way where you ship a super tiny bundle that doesn't have dependencies at all.

So it's a win from a DX perspective and from a code-you-actually-ship perspective. The thing you have to watch out for is that it's newer and doesn't have as much community support as the other two.

But if you're doing React or Vue, you really should at least do a Svelte Hello World. If Svelte doesn't eventually replace one of these, something like it is going to. It's kind of a matter of time at this point because the benefits are so obvious.

This is why, when this whole build tool thing started happening, people started talking about Vite and Snowpack and using it for React.

00:39:33 - Anthony Campolo

I was like, "Yeah, the Svelte people have been talking about this forever." You'll see these things pop up at different places in different communities. If you pay attention to all of them, you'll inevitably be ahead of the curve in the other ones.

00:39:46 - Sean Washington

Yeah. It's the same thing in MVC frameworks too, right? Similar ideas, similar innovations. Seeing LiveView happen, then Livewire happen, then Hotwire happen, all in a row like that. Similar concept.

00:40:04 - Anthony Campolo

You can go back to Django versus Rails, right?

00:40:07 - Sean Washington

Yeah. I forget now. LiveView is Phoenix, Livewire is Laravel, Hotwire is Rails.

00:40:17 - Anthony Campolo

Yeah.

00:40:17 - Sean Washington

And I'm pretty sure that Django has one too. I don't know.

00:40:22 - Anthony Campolo

Yeah, those are interesting. Those are things I want to learn more about because I don't know any of those frameworks or even those languages. But I know those things are part of the same conversation with Redwood. It's a different angle to it.

It's all wrapped up in this thing of, how do we make full stack applications? How much are you going to a single-page application versus keep it on the server? Knowing all the JavaScript stuff is only giving you part of the narrative until you see the other part with all these other back end things.

00:40:54 - Sean Washington

I like that. That's what your perspective is like, the whole, like you said at the beginning of the show, the holistic picture. I think that's a really healthy way to look at stuff, or a good way to keep yourself grounded.

00:41:08 - Anthony Campolo

Yeah. I think this is one thing I picked up from music. Funny enough, I don't usually go into the things I learned from music in coding-type terms. I think most of it's crap.

But this was a thing I learned: how to look at a scene and assess what's important, and then how to be aware of the sum total of scenes that exist for music. It's genres. You have your metal heads who listen to metal and your country fans who only listen to country. You're not going to meet a lot of people who are both metal and country fans, but there's no inherent reason why you can't listen to both, appreciate both, and find masterpieces created in both.

So I made a point to try and find whatever the good stuff was for every genre and not assume a priori that this isn't my kind of genre. And it's the same thing with all these tools. People come up with these things with certain perceptions, or people are just never going to be happy writing JavaScript.

00:42:04 - Anthony Campolo

They've decided they don't like JavaScript and TypeScript. If you have that sort of attitude, you're going to miss stuff because you're going to say, "I don't need to learn this thing," so you're never going to understand it.

You don't have to go all in on it to at least learn enough of it to understand it. But that requires having a loose filter. If you have a really tight filter in terms of where you're going to look and what you're going to consider, you miss things.

It's kind of like trusting the process that when the larger community is all talking about something, there's some reason for that, and at least understanding what that reason is will be useful for you and possibly a growth opportunity.

00:42:43 - Sean Washington

Yeah, to go back to the music analogy, I think exposing yourself, as a musician, to multiple genres or ways of writing music is putting more tools in your toolbox. If you're composing, you have more tools to choose from. You can maybe not be more creative, but you have more at your disposal to express yourself.

00:43:06 - Anthony Campolo

Yeah, I would say it does make you more creative because having a wider palette of things you can do allows for a wider space of creativity. You nailed it.

What I didn't say is the reason why I actually wanted to listen to all these different kinds of music is because then I was aware of all the different things you can do. So I could learn how to improvise a jazz solo and take that to a rock band, and the rock players would be like, "Whoa, I've never seen anything like that."

At the same time, you learn a really cool beat from hip hop and take that to jazz, and the jazz folks would be like, "I've never heard something like that." So you can't assume ahead of time that all the interesting things are monopolized by one of these groups.

00:43:48 - Sean Washington

Yeah. And building on top of that a little bit, it's been interesting to me recently. I've been going back and listening to bands that some people would call seminal in different genres.

For example, I was like, "I've never really listened to grunge music," but it seems like there are a lot of people that like grunge music. The first band you think of when you hear grunge is Nirvana, right? But then you start going back and listening to Nirvana's peers or the people who influenced them, and you hear some of those bands. Then you go back and listen to the other bands you listened to. You're like, "Oh, okay, these just sound like this band that was ten years earlier."

00:44:25 - Anthony Campolo

But Mudhoney was kind of the source of a lot of that grunge stuff.

00:44:28 - Sean Washington

Yeah, Mudhoney. And what's the other one? I keep forgetting. The guy who overdosed? Well, a lot of them overdosed, right? But one of the first ones to overdose, Andrew Wood, I think, was the guy that overdosed. I forget what his band is called, but anyway, you start going back and listening and you're like, "Oh, this is familiar because I've heard this other stuff."

00:44:54 - Sean Washington

Yeah. That song, I'm not a huge grunge person, but that band Temple of the Dog, one of their songs, "Hunger Strike," I think, was written for Andrew.

00:45:08 - Anthony Campolo

Hmm. That's cool. Yeah, I was actually the same way. I was never super into grunge, but I ended up appreciating Nirvana's later stuff, like In Utero and the acoustic album they did. Those are really good.

Then I ended up liking Alice in Chains a lot. I felt like out of all the bands, Pearl Jam is good, but I'm not really that into them. Then you had Soundgarden, which had their own kind of flavor, which was good, but I wasn't super into it. But I always felt like Alice in Chains hit the right combo of grungy and really melodic.

00:45:40 - Sean Washington

Mm-hm. Yeah. So Layne Staley was one of the people I was going to reference. You listen to him and then you go and listen to more bands in the 90s and you're like, "Oh, it's Layne Staley," or people that sound like Layne Staley.

Same thing with that topic. When we had Eric on the show, he wrote "Grokking Simplicity," right? He was talking about going back and reading papers and white papers and research stuff, and then trying to relate it to what he has been learning recently or learned more recently.

00:46:16 - Anthony Campolo

What's hilarious is when you had him on, I saw you advertise that beforehand, and I didn't realize until he started talking that I'd already been listening to his podcast for like two years.

He has his own podcast that's super obscure, and he did a two-hour-long episode about the entire history of Smalltalk. It was amazing. You're not going to hear that anywhere else, like any other podcast.

He has a historical perspective that I very rarely see from programmers. So I was super stoked to see that.

00:46:48 - Sean Washington

Yeah, it was really cool. I'd love to have him on again at some point. We've kept in touch a little bit. It'd be cool to have him on, give him the mic, and let him go and see what happens.

00:46:58 - Anthony Campolo

Yeah. And I think he has a solo podcast, so it's him just talking. That takes guts to do that.

00:47:04 - Sean Washington

Yeah, definitely. Well, cool. Man, I know we're rolling up on an hour.

I just wanted to ask if there's anything else that was on your mind that you wanted to talk about more specifically.

00:47:17 - Anthony Campolo

I would say the last thing is that I'm trying to unify all my worlds with some StepZen example projects that actually use Redwood.

This has been really interesting because StepZen, as I said at the beginning, is a way to spin up a GraphQL API gateway really easily because it's managed. It's a way to connect to a wider range of backends than you would traditionally be able to do with a Redwood app.

If you think about it, we've talked about Postgres a lot. You have Postgres, you have Prisma, you have this whole back end already built out with Redwood, and it's very self-contained. But with Jamstack, a lot of it is how do we use things like Shopify and Airtable and all these headless e-commerce things and headless CMS. There's not really been a super good story for that with Redwood, aside from just bringing node-fetch and making a fetch request.

00:48:17 - Anthony Campolo

Whereas this is a tool that already has a lot of built-in integrations for you and has opinions about how to do key management and how to actually secure some of your other back end systems.

So I have a Redwood example app with Shopify. The Shopify thing is connected to the StepZen API, and then the StepZen API is queried from Redwood's backend, the Redwood API folder, because it has to make a request with your StepZen keys. So you can't do it from the front end, because then you can just go look at your source maps and see your keys.

Redwood turned out to be perfectly architected for these types of things because they already figured out how to make a GraphQL request, mask your keys, and have it be deployed on a Lambda handler for you, because that's what most people use serverless functions for.

And someone asked, "Can I put [unclear] in front of a back end?"

00:49:13 - Anthony Campolo

That's all gRPC. If you ask hard enough, they'll figure out how to do it. It's a bunch of old-school API people from Google and Apigee. So I have no doubt they speak gRPC in their sleep, but I don't think right now that is a thing we have a particularly good story for. It's certainly something that is capable if there was enough demand for it.

00:49:39 - Sean Washington

Yeah. So the idea of the gateway, or at least having your self-contained app. When you look at that, like, okay, Redwood has Prisma, Redwood has these tools here, I feel like I have to build everything inside this umbrella of Redwood, which isn't the case.

You can have your own local services and make calls out to any other service, just like you would in Rails or Phoenix. So what I've been doing is using Firebase for auth and then Prisma for my DB stuff, but then just like any other monolith, you could hook up to Mailgun or Mailchimp or any other services.

So you're basically just using StepZen as a universal translator of sorts, right? StepZen is the thing that talks to all the other services, and then Redwood talks to the single service of StepZen.

00:50:29 - Anthony Campolo

So not only does StepZen talk to all of those things, it consolidates them into a single GraphQL schema that you're able to query against. One of the big things here is that because your Redwood app, or any app you have set up for GraphQL, just has a single GraphQL endpoint, you send requests to it, and GraphQL itself has the read, write, update, delete things built into the query language itself.

It's about saying, okay, we already know what we like about GraphQL. Lean into that, and how do we make this all work as a single graph that we can just send queries to? You may have to send that query through multiple layers to get the thing you want, but as long as they all have the same schema, they have the same types, and it works.

00:51:16 - Sean Washington

Right? I can imagine that would be really empowering not only for a front end team that would be using it, but because you'd have more people working on a Redwood app than just front end people.

And having a single graph, and because it's GraphQL, you have the documentation, you have the types, you have everything kind of there. The tooling is really nice these days too. So I can imagine how that would probably speed up development quite a bit.

00:51:46 - Anthony Campolo

Yeah. And it takes a little bit of time with most of these things. It's the cognitive burden of having to learn GraphQL and actually know what you need to know and what you don't need to know.

This is why I consider myself very fortunate that I had been doing all this Redwood stuff, because Redwood is talked about as a React thing, but it's much more of a GraphQL thing than a React thing. I'm pretty sure we talked about that on the last episode too.

I already knew what a GraphQL request was, and I already knew what a GraphQL schema was. I had a mental model for it that was like, "Okay, so now we're in the StepZen-isms because you have directives."

I've been learning a lot about directives, which I think people don't talk about very much with GraphQL because there's the @ symbol and there are four built-in directives that people very rarely use.

00:52:34 - Anthony Campolo

Let's see, I have a blog post for it up right here. Not one that I wrote, but one of our colleagues did. So: @skip, @include, @deprecated, and @specifiedBy. What those exactly do is not super important for this, but the idea is that it's a way to extend the functionality of your GraphQL server.

There are built-in directives, those four I just named, but you can create your own. That's really what StepZen does: they've written their own directives to connect to either a database, a REST endpoint, or any GraphQL endpoint at all. That's where a lot of the magic is happening.

But because you're still writing the same queries, you're still writing the same schema, and you're still working with it the same way. All you have to do is figure out those couple little StepZen-isms, and the rest is familiar.

00:53:22 - Sean Washington

So now I'm just curious: is @skip allowing you to make sure something doesn't get included in the external-facing schema?

00:53:32 - Anthony Campolo

It says @skip may be provided for fields, fragment spreads, and inline fragments, and allows for conditional exclusion during execution as defined by the if argument.

00:53:43 - Sean Washington

Ah, okay. And @include, what does that say?

00:53:48 - Anthony Campolo

Let's see. So @include allows for conditional inclusion during execution as described by the if statement. So it's the opposite.

00:53:55 - Sean Washington

The opposite. Yeah.

00:53:57 - Anthony Campolo

Yeah, they deprecated this one. Actually, @deprecated is easy. You basically say something is deprecated and then give a string with the reason, like a message to the user. That was a smart thing to build in.

And then @specifiedBy is, you can point to a URL with a specification for a scalar type, like what's your date type, that kind of stuff.

00:54:20 - Sean Washington

So just link someone to additional documentation.

00:54:22 - Anthony Campolo

Links to the example, like an RFC, one of the Internet Engineering Task Force.

00:54:31 - Sean Washington

The heavy ones, the wall of text.

00:54:35 - Anthony Campolo

Yeah. The one that starts with a list defining what the word "must" means.

00:54:39 - Sean Washington

Yeah. This is giving me the itch to... I've been doing a lot of front end stuff at Metalab and it's been a good learning experience, but I've definitely got the itch to do some API, some back end work.

Overall, I think I enjoyed the back end side of things a little bit more. I enjoy working in that day to day. Honestly, a lot of that's due to tooling. But yeah, I've kind of gotten the itch now to do something on that side of the fence.

00:55:10 - Anthony Campolo

Cool. One more thing I want to mention that we can finish off here is that there's something really interesting happening with Redwood's back end, where we are potentially going to make it possible to swap out Apollo Server.

We already did this with Apollo Client, making it swappable with a React Query provider. And it's going to be swappable with this thing called GraphQL Helix and a thing called Envelope, which is a kind of next-gen GraphQL server meant to address the problems with Apollo Server.

So it makes sense why they're like, "We need to get these guys to use it." It's from The Guild, which is a group that's a bunch of people who work together in a decentralized way. But it's mostly spearheaded by Uri Goldshtein, who is one of the founders of Apollo. He's been doing GraphQL since it was invented.

And the thing is, going back to the problems with Azure, Thomas will know this very well when you try and deploy Redwood to Azure.

00:56:06 - Anthony Campolo

The thing that breaks is Apollo Server Lambda. There's a specific package for deploying Apollo Server to Lambda itself. To take that out and replace it with Apollo Server on Azure, it's not quite the same thing because these weren't thought of as something that was going to be portable from the beginning. Going back, you have to think about these different products from the start.

GraphQL Helix is meant to be more plug-and-play and can be more easily deployed to different deploy targets. I have no idea how it works; it's so new. There's not a lot of docs and stuff, but there's been a PR going, if anyone wants to check it out. It could potentially be a game changer for the framework in a way that is very hard to understand unless you're very deep into this tech.

As someone deep into this tech, this is definitely interesting. No one knows why yet, but this is very interesting.

00:57:04 - Sean Washington

It took me that long just to find the Envelope.

00:57:08 - Anthony Campolo

Yeah. Envelope wasn't even announced until like a month ago.

00:57:11 - Sean Washington

That's cool. I mean, yeah, there's a lot to dig into there.

00:57:17 - Anthony Campolo

For next time.

00:57:19 - Sean Washington

Yeah, we'll have to have you on again for sure to talk about more of the technical specifics of this stuff because it's definitely interesting.

00:57:28 - Anthony Campolo

Yeah. Thanks for having me. I really have enjoyed getting to continue to hang out in the Discord and come to show tapings and whatnot. Awesome community you got, and I very much enjoy being a part of it.

00:57:39 - Sean Washington

Oh, we're glad you're around. Like I said, you're always dropping links in, and I'm like, "I've never seen that before."

Part of my learning and staying up to date is looking at whatever you're tweeting about or who you're replying to. I basically just scroll on Twitter. I never tweet. So I follow you and I get a lot of information from just you talking to people.

So, yeah, we're glad you're around and you're sharing your information freely. So cool.

00:58:11 - Anthony Campolo

Yeah. Happy to.

00:58:13 - Sean Washington

Cool. Well, yeah. I'll circle back up with you and we'll have to get you on again. But until then, keep up the good fight. I guess you got the energy. I'm going to ride your coattails.

00:58:27 - Anthony Campolo

Yeah, I'm still enjoying it. We'll see. We'll see when I burn out.

00:58:30 - Sean Washington

All right, man, we'll talk to you soon.