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.

Blockchain World

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.

Anthony: It is cool because it can work with anything you want; you use it as quickly with a view or vanilla JavaScript in terms of different front-end technologies. We are going to have various examples that we're building out, different ways you can use it so that whoever comes to it will be able to meet them halfway, or it's a big task to have someone learn not only to GraphQL, but then this tool built on top of it. So, we have react frontend, crazy graphical stuff in the back that we can set up for you and give you good defaults for and then you can just write those out most of the front-end stuff yourself. That is kind of a similar idea to what Redwood was to a certain extent. It allows us to think in a similar mindset like the fullstack and the front and back end, how it fits together into this, and more.

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?

Anthony: Yeah, absolutely. Since these are all APIs on the open Aironet, it's very easy to start to stitch them together with these serverless functions, to where this all kind of started, the Lambda. Going back, I won't be able to write these functions and whatever language as long as that language is JavaScript or Python, and eventually, they add a bunch more languages. But the real idea was, you want to be able to write code in the language that makes sense to you and deploy that code to the world. So, you can create Google Cloud Functions that will stitch together different parts of your back end. Now, you shouldn't have to do that kind of stuff.

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.

There's a whole serverless guide that just came out last month on AWS, a recommendable one. There is also an entire section called anti-patterns. The first anti-pattern is the Lambda model. So, we are the anti-pattern because the server lists are the embodiment of the anti-pattern. But it works to the extent of like you put that sucker on wine head, and it's going to give you information back. You hit a point where you need to start breaking it off into smaller pieces to get it to work the way. There is a strange tension between the different types of JavaScript you're writing; either the different types of node you're writing is everything about Lambda versus Azure versus Google. They're all giving you nodes, and they have different levels of node 10, or 12, or 14. They have slightly different semantic terms, like context object versus event object versus callback object and how you deal with the requests or responses. Because with Google, you just kind of bring in Express. But that's not exactly what you get from, from the other ones.

The next level is Cloudflare that doesn't give you nodes at all periods. If there is no note, this confuses people because it's running out of VA. I was like, that's just not how this works. They took the thing that the note is built with, and it made another thing. So that's why you can write JavaScript, which will be agnostic to any of that stuff. So, there are many layers to this as all are very baked into the progression of JavaScript, the language and node and ESM. That's interesting and very confusing for people.

Challenges

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?

Anthony: It is not something you can just choose to not think about. This has been a huge priority for Redwood, and all credit goes to Dominic Dom as he has spearheaded this work. What is cooler is that we did a whole stream with Ben Meyers on the semantics stream. We walked through what Dom did here, and it's about the router and about how single-page applications work at a kind of fundamental level. Sometimes, you don't know the difference between old school server-rendered rails and current JavaScript.

The main thing is that all the code lives on the server; the code lives in the frontend. So, if all the code lives on the server, like Rails, you generate a whole bunch of HTML and throw it over the wire. If it is something like RedWood or these single-page applications, you have a bundle of JavaScript that is like the logic and the website itself. As you click the links, you're not sending another request back to the server to get a new page because if you're navigating around different pages with different HTML, you're hitting the server each time and trying to get those pages and navigate. But that's not how single-page applications work. When you click the links, JavaScript is being executed in your browser to navigate. It breaks many assumptions of how the web works and how screen readers need to interpret your site. It is very simple when you would click a link; it would know that you would navigate, you wouldn't be able to announce that you'd navigate away from the page. So, if you want to go to your contact page and hit contact, you have a screen reader. When you navigate to a page, you like to say what the thing is, but you can't see that you're listening to it. Hence, we had to hack it into RedWood so that it would look at the page, find h1, and then make that the title. It is like a route announcement component.

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.

I'm looking at these kinds of options and amplifying being another one. I find that they each connect from a different angle x cDk. You write code, like in JavaScript, or Python, or TypeScript or something like that. First thing, it's imperative. The Sam, the service application model, is from the info layer. You are starting to think about YAML, and your configuration is deterministic. But you are still deploying full stack things with code. It's just about like, where are you writing all that code or where are you centering it and how you want to structure it? Then, you can amplify things about it from an app level. That's why there are three of these things in there. They're all meant to give you a single, pleasant and integrated experience on AWS. You should focus on what you should optimize around and say; I've been building a little proof of concepts, and it's a great way to get into cloud formation. It lets you write more excellent syntax which makes sense. So, you just kind of like a way into pyrite stuff. It makes sense.

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?

I usually think that if you need to give a default answer, you should go with the most stable one, who is the least likely to break and change. But there's also another question I think of an app that's going to be live, like who is inheriting this app? Where are they coming from? What would be the tool that would make the most sense for them? Can we write in any language? So, we're at the point now where most of these have serverless runtimes and good support for JavaScript and Python. First of those, maybe the first two, and then you get kind of Ruby and PHP is the next to the kind of dynamic languages, then Java and dotnet and go for your static languages. But with things like web assembly or VHDL, I think that's super close. I like conventions and having opinions. You have to be aware of the different sets of views available to you so that you can weigh that against each other. Build your own thing, but you can't do that until you evaluate the options first.

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.

A vetting process is important. So, Lambda did this, and most boot camps do this, where they have you build a super simple HTML, CSS site, and then do some JavaScript examples that run tests, write a function, and stuff like that. So, that's like the base you want to do this, and if you can't do that, I do a code school. Yes, there has to be at least something like that, being open to everyone and accessible to everyone.

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.



Conclusion

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.