Ep 38: Anthony Campolo Returns!
Hello, and welcome to the Talking Serverless podcast. This is your host, Josh Proto, and I am delighted to welcome our guest Mr. Anthony Campolo for another exciting session. A Developer Advocate at StepZen, Mr. Anthony has worked extensively on many Open-Source projects. He is the Lead Developer Advocate on the RedwoodJS Core team, where he contributes articles, podcasts, and presentations about the framework. He has spoken about various open-source projects on podcasts and at meetup talks. Moreover, he is a well-experienced techie with experience in the different frontend, backend and deployment technologies.
Josh Proto Q: The Blockchain world is embracing Serverless and GraphQL. Why is GraphQL valuable, and what is it like using the program?
Anthony: It is a managed GraphQL API gateway. It makes it easy to spin up a GraphQL server, so you can have an endpoint, hit it, and you can do anything you want with it. Also, it lets you stitch different back ends and different data types together into your one unified schema. It is an excellent tool for integrating different pieces, so the Blockchain graphical stuff is exciting. So, it's a tool that leverages GraphQL and gives you a nice COI with the whole built-in deployment thing. They are hosting that API for you as well. Other open-source projects are doing stuff like GraphQL mesh, but you'd have to run that yourself. I feel that this is just like, not only do they have this whole thing built out, but you can also get your point up and have a whole project going quickly.
Josh Proto Q: Do current projects have Keystone/Blockchain use cases or is it a variety of other use cases?
Anthony: It is not Blockchain, but it is more in the JAMstack and react frontend area right now. It is also about getting different backends, like, Shopify, Air Table or, various e-commerce things, and headless CMS. It is how do you stitch that all together. Hence, that is unified for your frontend. That is how Redwood was. Redwood is a react framework with a GraphQL kind of middle layer that lets your friend at your back-end talk to each other.
So, I had been doing work with Redwood, and then the CEO of steps saw what I was doing and reached out to me. It is really cool because, when I first talked to you, it was like, I was still coming out of my bootcamp, and I'll pay off. One of the things you'd asked me in a previous episode was, like, what I got out of open source or whether it was worth it or not. Then I said how it paid off 100 bucks a million times, but there are many alternative realities where it worked out that well.
But it's been a way to expand out for me, all the 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, and you take it and run with it and not think about too much. It is really nice. But at the same time, you have a hard time grokking like, what is Apollo's average rate at Oracle? It is a tricky question to be answered. You have to dig into this stuff to start to understand it. That is what I've been working on and getting spun up with over the last couple of months. I do a similar thing to what I did with Redwood, where I'll build-out projects and blog about it. I will do live streams about it; I'll get to podcast interviews about it. Now, I can understand subs that now I can kind of build with it. I can communicate with it and start dialoguing with people about it and what they see.
World of Redwood Approach
Josh Proto Q: How is Redwood leveraging and working like GraphQL? Also, what are some exciting things going on with Redwood that you're looking forward to?
Anthony: Yeah, Redwood was originally architected for GraphQL. Having worked with Redwood set me up well to get what was happening with StepZen because GraphQL is a spec. So, for people who've never got the whole GraphQL, it's a query language for API's, and it's a way for your frontend end to talk to your backend. This is like throwing JSON objects back and forth if you smash that JSON object with the keys. It's like a key-value pair, just the keys, not the values. So, you say you want a person, and then you want their name. Then, you'll get back a name like Josh, which is how the query response is. You can do mutations as well. You can create, read, update, delete, all combined within this query language. For Redwood, that query language is how you react to frontend talks to your backend, like via Prisma, which is like a step in the chain. But still, GraphQL gets you from the front to the back. Tom and pier created Redwood based on their experience building Shutterbug, which was a language learning platform that involves a react frontend speaking GraphQL to a Rails backend. Hence, they want to build a framework that would better integrate these kinds of technologies.
What it doesn't really do is, let you reach out beyond itself, like a full-stack framework, the whole idea of a Ruby on Rails kind of thing. But part of this entire JAMstack idea is how we pull in other APIs to do all this other functionality because you get this gateway that becomes another step in the chain so your frontend can speak. So, your Redwood frontend can speak to the back end of the Redwood API, and that API can talk to your StepZen API, and so on. Hence, it opens you to this wider world of possibilities of what you can do with a Redwood app. As a Redwood developer, you could not just write all that logic to translate all these different rest APIs into a GraphQL schema. It is just not the thing that you have the time and experience to do. But that's what you can do with StepZen. It gives the ability to write these kinds of schemas and then plug in endpoints and do that whole translation.
Josh Proto Q: How is it in the cloud services world? Is Vendor Lock really a problem? If we have access to an infinite amount of API's, that is just better for the ecosystem in the long term. One of the Golden desires of open-source projects is mass adoption.
More about Gem Stack
Josh Proto Q: What are the new developments with Gem Stack and how have they been leveraging serverless and serverless components?
I've been going very deep down this rabbit hole because we're in the process of trying to make Redwood as portable as possible. We haven't talked about vendor lock at all the time and whether your thing can kind of work cross-platform. It was designed for Lambda, specifically AWS Lambda. Your entire back-end API is one giant Lambda function and is something that if you listen to the last serverless people, you'll freely hit and sit specifically tell you not to do this.
Josh Proto Q: What sort of challenges are you facing with human disconnect?
Anthony: I can tell you specifically where the Apollo server broke out. So, Apollo server Lambda is where the actual functions API thingamajig is being deployed. And traditionally, what has happened is that it gets deployed on netlify. Netlify is running your Lambdas under the hood for a column. Now the five functions are Lambdas, and that is what you would do. But 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 have to extract out the Apollo server entirely. There is an interesting project called GraphQL helix from the guild that is potentially going to integrate with Redwood support; we can make the server swappable because we made Apollo client swappable back in January. This allowed us to have a react query provider.
React query is a data fetching library for react. So just like hitting an endpoint, doing a query and getting data back and handling all this goes along with it by Tanner Linsley, and it's massively popular right now in the React world. So, the Apollo client is how we handle the stuff they would do that the react query does. You would have to figure out how to do the actual GraphQL calls itself. So, what you do is you have a react query with GraphQL requests, which is a lightweight graphical client; they put them together and swap out Apollo for that and then you have your Redwood now decoupled out the Apollo client. Thus, we're getting close to what we need to do the same thing with the server. Hopefully, it will allow us to plug and play this with all these different deploy targets in similar ways. We don't have to rewrite the API for every single deployed target.
Josh Proto Q: What is the timeline for this on the roadmap?
Anthony: The Cloudflare is not on the v1 roadmap; this is the stuff that I am doing as I find it interesting. I know people who can help with it. This stuff requires expertise on both ends to make it work. But the render stuff is what people should be looking at because that will be one of the best ways to deploy these kinds of apps. What render has is some sort of like a Heroku. If you are one among the people who haven't used it, you also get a lot of that nice kind of frontend de netlify, static hosting type stuff. It is very much like the full stack, as you get all the cast stuff you want. Then you can build your whole project together. We would deploy the frontend on something like a netlify or oversell, and you grab a database environment variable for somewhere like a Heroku or like a railway. Whereas now on render, you host the full stack entire app on render specifically. So, it's like getting my IC ultimate vendor lock-in.
But if you're okay with going into just one platform like your code doesn't have to change at all because you don't have to rewrite the API. Hence, all these different hosting providers have ways of building your assets and sending it to them. You have to figure out exactly how their system wants to get those assets. So, I'll do it a little bit differently. All the frameworks do it a little bit differently. Thus, everyone's kind of trying to align on how we want to do this and what's the best way to do this.
There are so many things happening around there. But for us, like v1, it's about making sure the framework is solid. This means we are getting things like TypeScript support and accessibility features, route announcement, which ended up adding a couple of little bits after. It's cool to see all the actual pieces of the framework come together. Then there's going to be a big push for a more integrated tooling kind of experience with the VS code plugin. Thus, there is going to be deploy targets and features in the framework and get a stable before v1. That's pretty much like where we're at right now. And hopefully, it'll be soon.
Accessibility and Features of Redwood Approach
Josh Proto Q: What are the accessibility features/accessibility issues for the Redwoods approach, and how can they be solved?
This was based on work from the Gatsby team and Marcy Sutton, especially those who researched and tried to figure out how to make Gatsby's router accessible. So, there's a lot of research behind this, and it is a deep, technical, specific problem. But this is why we want to solve it at the framework level because having every router develop or figure out how to do this themselves just doesn't make any sense. We can leverage the fact that we're fair with opinions; we bake in accessible opinions; that's a huge win for everybody.
There is a lot to dig in there in terms of 100% accessibility. Just a couple of days ago, we had a whole episode about accessibility. Many downstream effects are nice from thinking about designing for accessibility, which is good for everyone. I appreciate that you can't ever dissenter; the disabled person's experience in this topic is the point of making it accessible. Thus, it requires dialogue with people who use these technologies and using them yourself, and how they work. There need to be questions like the implications of your software and when these pieces of technology are being used?
Josh Proto: Ultimately, you're going to make a better product or an application at the end of the day, making it a win-win situation. I have noticed our consultants talk with clients. It is like, what's your end goal so that you have a perfect understanding for the clients, especially if they're coming to us. They are like we're on Lotus servers, and we want to go serverless, or it's like, we have no experience, and we need to do this lift, and what should our milestones be? Thankfully, you know, there's a lot of great talent on our team who knows so much about serverless. Because of its technology, you are going to have a better product. It sounds like Redwood is developing with that, and I can't think of many other frameworks or programs that are really featuring it in that way.
Anthony: Yeah, totally. We can even get into meta frameworks that we talked about last time. We are using that term for Redwood because it is built on react, and there are AWS meta frameworks. You would use the serverless framework, as it is a better and different framework, but it's the same idea. I've been playing around with many kinds of things, the main ones being CDK, Sam, the serverless application model and the cloud development kit.
It is interesting to know that they could potentially merge into a super tool. That's not something that a RedWood Blitz could do as it defeats the whole purpose. Whereas what is cool about Sam and CDK, you also get an excellent integration with the infra itself because you're getting cloud formation handled for you under the hood. This is where Redwood has run into a lot of problems. We have not had deterministic builds because we've had the crazy yarn moto repo set up; we have to get a package dot JSON for your web package and JSON for your API's; you had to figure out how you copy both of those and then build them both. It is like a huge, ridiculous pain. So, by having a setup with your Infos code, it is much easier to do that.
Most Popular Frameworks
Josh Proto: That's definitely one of the benefits of those tools as it lets you familiarize yourself with a theory of best practice. I think that's always a huge challenge, especially if you're trying to roll out those sorts of skills at a team level, as everyone has different levels of familiarity. But if you're able to work in a common style, then you're just going to go a lot faster. Hence, you're not trying to mix the preferences between different team members, which may or may not make sense down the line, especially if, you know, that whole team or two people among them decided to leave the company. Then they're stuck in between. I've had people in the serverless space and at that framework level, and I think we're moving towards finding the best practice that we want to continue to multiply it within the industry.
Anthony: I am curious to ask you this. So, if so, someone comes to you, and they say they are building a stack, and it's all on AWS. They ask, how do I build that? Should I use the serverless, or should I roll it in Sam? How would I think they just give you that blanket question?
Josh Proto: I would say that the serverless framework is the way to go just because it is. As serverless guru, it is like a third-party application, with the plugins and the support, and we're able to leverage everyone else's use for our use cases. However, certain fringe cases in which languages are not supported demand requirements from the client when they say; this is all in C sharp or Java. Then, you're at a point where all things are not being equal. At those times, it's like, oh, we should use Sam, or we should use something else. So, I think about the serverless framework, art codes, or Sam using CDK. I remember we did a poll on Talking Serverless. A while ago, I was like, what're the most popular frameworks you like to use? The serverless framework was extensive, but a lot of people stood up for arc codes.
Anthony: The arc is incredible. I've tried a little bit with arc and like to play more with just arc because it's going back to the abstractions like cloud formation. So that's a cool idea.
Josh Proto: Yeah, I think it's innovative. People don't know about them, and they check it out. There is always a question from the consulting side, like how do I decide to use one service versus another? As a consultancy, we have to do what's in the client’s best interest. The institutional goal, the business goal, and the departmental team goals are all related, even though they're measured differently. When using niche tools to know the speed, we need to move as safely as possible. We can't use the newest sort of thing, or it could work in one instance. But as far as you know, we can guarantee this will be around in 10 years because many companies are looking to make their next 10 to 30-year decision. So, we'd like to consider all those things when recommending, like, oh train your whole team on Sam or train your entire team in a serverless framework.
Anthony: Yeah, I think you want to train your team to know at the base layer to do any of those frameworks because ultimately, most of them are doing the same thing at the end of the day. So, once you understand actual infra underneath, you've got the pain of clicking around an AWS dashboard to set it up and then have someone give you a whole just line of code, like here it is you try to do it. You then have to look and ask, how long has this thing been around for, how is it stable? How is it similar or different from other things?
Thoughts on Technology Builder Education
Josh Proto Q: Absolutely. If one can understand the decisions at the frontend, you are having that documented. So, it's good to have those solid foundations.
I saw on your Twitter profile; you added another thing like Lambda, school dropout and serverless Guru. So, what are your thoughts on technology builder education? Is there a future for code schools, and is there a code school model that you think will be the best?
Anthony: Regarding the Lambda school dropout thing, I'm trying to capture the nuance inherent to this conversation, which is, in one sense, an endorsement of Lambda. I'm like, branding myself along with Lambda. But it's also like, why'd you drop out? The fiscal is so great, shouldn't you have graduated? Will you get a job in terms of the curriculum regarding how the assignments are structured or the payment structure? So, you have to ask those questions.
First of all, Lambda has been in the news recently for people who follow Silicon Valley. People have been asking me about it and to comment on it. I think it comes down to the churn inherent in what they're trying to do because they're offering this platform for anyone to come in and start doing it without paying a single dollar. People can have access to it. That is not something that aligns with the way we usually think about this kind of stuff. It is hard to teach people to code, and it requires a lot of time for a specific type of personality. But anyone who wants it can put time and effort to do it. But the problem is most people get into it, not really knowing what it's going to be. People don't necessarily get the best information about these programs beforehand.
So that's why I try to capture the nuance that going to Lambda was a positive thing. It helped me get to where I need to contribute to Redwood; Atlanta didn't get me a job. The reason why that happened is that I essentially dropped out of Lambda. It had already worked out months down the line, so you want to just talk to students who've gone to the school and speak to people who have taught at the school. Dustin Myers was one of my teachers who had been laid off in this round. He left saying that he thought his experience in Atlanta had been great. I think that speaks a lot to Lambda and what they built and the number of people who have helped. So, Lambdas are fantastic.
But getting back to why the laptop, I think there's a lot of churn in the program. So, they try new programs that could be amazing. It's going to be a more back end heavy, AWS DevOps heavy, integrated program where they learn how to work with AWS. So that could be incredible. It is also challenging as they have so much funding, like millions and millions of dollars. But one of my good friends is going there right now. He asked me about my experience and whether he should do Lambda or not. It's like two months ago, and I said that based on your experience, it would be good. He is doing great there and having lots of fun.
Josh Proto: I need to look at this new program because I like the idea of having an integrated process with AWS. That advice was given to me a long time ago. My partner went to Code School, and Ryan went to code school as well. Thus, I'm around an ecosystem of very successful people in their tech careers, going to Code School and boot camps, rather than having a four-year CS degree and a two years Master Degree in algorithms. So, it's great to see that there's more potential after learning the modern tools. You can do so many innovative things with knowledge of the AWS ecosystem.
I have been having more conversations with organizations and communities that organize events around like teaching students, either in code school or out of Code School; several serverless gurus who recently had their first official cohort of serverless interns. We got good feedback around like, Hey, we enjoyed it, and this was so different. You were making us sort of look at problems, figure out this could be a solution and then guiding us around like building it. They have been very successful and very fulfilled, right after a traditional Code School experience.
Anthony: Well, this is great that you mentioned this. There's this company, mint bean, with whom the founders have been good friends for a while. I do Redwood, and they do hackathons, which is called learning hacks. The idea is that people who are right at a code school are still trying to get jobs; it's a way for them to continue to build on those skills. So, people who are building these things can get some guidance on their projects and work with the tech. You can even get the feedback loop you can get from that is incredible. So, shout out to “mintbean.io” as it is amazing, and they are doing that exact kind of work.
Josh Proto: Do you have anything else that you want to share with us today?
Anthony: I'll point people to just stepson.com, where you can find us and what we're doing. Also, Fs jam.org is my podcast as well. So, those are all the kind of things I'm doing. Then, there's the React podcast. Discord is worth checking out as well. Those are two other things that are like open source. It is like this massive, crazy project that has a bunch of friends getting together and building something for fun, hacking something, building their skills, and making it into something awesome. We will be learning all this stuff like GitHub actions too. So, events dot watch dot dev is where you can find a lot of that.
Thanks for having me. I feel that you're like the serverless world, which is great because we built on top of it with things like Redwood. But I think that there are so many interesting things happening with these types of frameworks, and like how they're going to be deployed and how this is all going to be stitched together with these platforms. So, the more that people can kind of talk to each other, collaborate with it and wrap our minds around it, it's all for the better.
Josh Proto: Thank you so much. To those listening, this has been the Talking Circles podcast with Josh Proto. Hope you enjoyed the lesson and 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. Have a good rest of your day.