PodRocket on GraphQL 101 with Anthony Campolo

Episode Description

Anthony Campolo introduces GraphQL fundamentals, its history alongside React, how queries and mutations work, and shares resources for getting started.

Episode Summary

Anthony Campolo, developer advocate at StepZen and core advocate for RedwoodJS, joins Ben Edelstein for a GraphQL 101 discussion aimed at developers new to the technology. The conversation traces GraphQL's origins at Facebook around 2012, where the need to send smaller, more efficient queries to lower-powered mobile devices drove its creation alongside React. Anthony explains GraphQL's core concepts—its readable query syntax resembling JSON keys without values, the single-endpoint architecture that contrasts with REST's multiple endpoints, and the built-in schema introspection that serves as near-automatic documentation. The discussion covers mutations as GraphQL's approach to writing data, the relationship between GraphQL and tools like Relay and Prisma, and how GraphQL acts as a typed mediator between front end and back end regardless of database technology. Anthony shares his personal path from music teaching through Lambda School to open source work with RedwoodJS, offering a nuanced perspective on bootcamp education. The episode wraps with listener questions about exciting GraphQL developments like The Guild's open source tools, recommended resources including GraphQL Weekly and How to GraphQL, common misconceptions about GraphQL's stability, and Anthony's enthusiasm for the new generation of front-end build tools like esbuild and Vite.

Chapters

00:00:00 - Introduction and GraphQL's Origin Story

Ben welcomes Anthony Campolo, who introduces himself as a developer advocate at StepZen and core advocate for RedwoodJS. Anthony explains his role writing blog posts, giving talks, and hosting his own podcast, and Ben notes a previous Redwood episode for listeners wanting more depth on that framework.

The conversation quickly pivots to setting up a GraphQL 101 discussion. Anthony traces GraphQL's history back to Facebook's transition to mobile around 2012, explaining how the need to avoid sending excessive JavaScript to lower-powered devices led to the development of a new query approach. He notes that while GraphQL and React were developed in overlapping timeframes, GraphQL's public debut around 2015 built on React's existing momentum, with the philosophy of starting from the front-end developer's mental model and working backward.

00:04:52 - Relay, Schema, and How GraphQL Differs from REST

Anthony clarifies Relay's role as the bridge between React and GraphQL, handling client-side caching and normalization. He emphasizes that GraphQL is fundamentally a specification for front-end and back-end agreement on schema and types, making it language-agnostic—it works equally well with Go, Java, or Node backends despite its association with JavaScript.

The discussion moves to GraphQL's practical advantages over REST. Anthony describes the query syntax as resembling nested JSON objects with just keys and no values, making it intuitive and readable. He highlights key differentiators: GraphQL consolidates everything into a single endpoint rather than REST's many endpoints, and its schema provides built-in introspection that functions as near-automatic documentation. Ben and Anthony discuss GraphQL explorers and playgrounds, with Anthony recommending the Rick and Morty GraphQL endpoint as a hands-on starting point for newcomers.

00:12:25 - Mutations, Prisma, and the Database Layer

The conversation turns to how GraphQL handles data writing through mutations. Anthony explains that in GraphQL, all requests are POSTs—the distinction between reading and writing is handled by the query language itself through the keywords "query" and "mutation," drawing a parallel to the CQRS pattern of separating commands from queries.

Anthony then explores GraphQL's relationship with databases, explaining its role as a mediator that isn't tightly coupled to any specific database technology. He traces the history of Prisma's evolution from being entirely wrapped up with GraphQL to becoming a standalone ORM, and how frameworks like RedwoodJS manage separate GraphQL and Prisma schemas. This decoupling allows developers to swap between database backends like Postgres and MongoDB, representing a significant advance in ORM flexibility.

00:17:41 - Types, Tooling, and Anthony's Path to GraphQL

Ben asks about GraphQL terminology like input types, interfaces, and concrete types. Anthony explains how GraphQL's extensible type system connects to the broader JavaScript versus TypeScript discussion, emphasizing that typing enables powerful developer tooling including autocomplete, error messages, and even drag-and-drop query builders in graphical editors.

The conversation shifts to Anthony's personal journey, revealing his background as a musician and performing arts camp director before transitioning to tech. He describes learning data science first, then pivoting to web development through Lambda School, where he discovered RedwoodJS. Redwood became his gateway to GraphQL because the framework integrates GraphQL as its core data layer, connecting a React front end to a Postgres backend through a unified GraphQL server and client, with generator commands that spin up interfaces quickly.

00:23:53 - Bootcamp Reflections and Listener Questions

Anthony offers a nuanced take on his Lambda School experience, acknowledging its value while noting he ultimately dropped out to work on RedwoodJS instead. He advises potential bootcamp students to research options thoroughly, speak with alumni, and understand the unique financial obligations of income-share agreements, noting the inherent tension in a model designed to accommodate high dropout rates.

The episode transitions to listener-submitted questions about exciting GraphQL developments. Anthony highlights The Guild, a decentralized group of developers building interlocking open source tools like GraphQL Helix, Shield, and Mesh. He also discusses StepZen's work creating managed GraphQL API gateways that can translate both database schemas and REST endpoints into GraphQL schemas, illustrating how GraphQL is expanding beyond its original scope.

00:30:27 - Resources, Misconceptions, and Front-End Build Tools

Addressing who to follow for GraphQL news, Anthony recommends GraphQL Weekly newsletter, developers like Yuri Goldstein and Sean Grove, and emphasizes the value of listening to multiple podcasts to absorb the breadth of the conversation rather than relying on a single thought leader. For learning GraphQL, he points beginners to the official GraphQL website's tutorial and How to GraphQL for full-stack tutorials.

Anthony tackles the biggest misconception about GraphQL: that it's constantly breaking and unstable. He clarifies that GraphQL is a stable specification with an active ecosystem built on top, and that understanding the core spec should precede exploring frameworks and tools. The episode closes with Anthony's excitement about new front-end build tools like esbuild, Vite, and Snowpack, which use languages like Go and Rust instead of JavaScript to dramatically improve build performance, a transition he says is already well underway across major frameworks.

Transcript

00:00:00 - Ad VO

PodRocket is sponsored by LogRocket. A front-end monitoring and product analytics solution. Don't know what that is? Go to LogRocket.com. Thanks.

00:00:24 - Ben Edelstein

Hello everyone, and welcome to PodRocket. I'm Ben, and we have Anthony Campolo with us. Anthony, welcome. Could you introduce yourself to the audience, please?

00:00:33 - Anthony Campolo

Hey, what's up, Ben? Thanks for having me here. My name is Anthony Campolo. I am a developer advocate at StepZen, and I am also the core advocate for RedwoodJS, which is an open source JavaScript library where React and GraphQL are a very important kind of base layer of how it all works. We'll get into that as we go.

I go out and write blog posts, do meetup talks, and do podcast interviews such as this. I also host my own podcast, FSJam, which has had, I think, about five or six overlapping guests between our two shows. So we have similar interests for sure.

00:01:19 - Ben Edelstein

Definitely. And we've talked about Redwood before. We had David Price on the podcast a couple of weeks or months ago, a while ago. So, you know, if anyone is interested in the deep dive on Redwood, definitely check out that episode.

But today we discussed this a bit before the episode, and folks may see it in the title. We're going to talk about GraphQL and really look at this as a GraphQL 101 for folks who have not used GraphQL or aren't super familiar. GraphQL has been out for a few years now. It's been growing tremendously in popularity, and it'd be great if we can do an introduction to what GraphQL is and how it helps you build great web apps. Anthony, maybe you could start there at a high level. What is GraphQL? A bit about the history, and then go from there.

00:02:02 - Anthony Campolo

I'm a big history buff, so I always enjoy learning where these things came from, especially for something like React and all the stuff that goes around it. React came out of Facebook transitioning into the mobile world. You're going to hear people talk about this time where Facebook went all-in on HTML5 and this new web thing meant to get us to a place where we were using native web APIs. React was a different thing back then. It was all about one-way data flow so you could do really nice data fetching, and it went along with this thing called Flux.

So let's step it back and talk about what the actual problem was. The problem was that you can't just send a ton of JavaScript over the wire, because it's a lot of code. Our devices can't necessarily handle all of that code and can't do all the things we want them to do.

00:03:14 - Anthony Campolo

So what we needed to do was send smaller queries for lower-powered devices. This sounds kind of esoteric and specific, but it had huge implications for how we thought about what GraphQL is and how we would want to work with it. That's the history of where it came from. This was almost ten years ago when it first started. It eventually hit the scene. Most people knew about it around 2015, and now we're seeing the downstream effect of it.

00:03:53 - Ben Edelstein

Got it. So does GraphQL predate React? Is that correct?

00:03:58 - Anthony Campolo

It predates it in the sense that it started around 2012 or so. React came out around 2011 but wasn't really released to the public until around 2013, so they're all kind of overlapping. By the time GraphQL made its debut to the world, React was already a thing and people had heard about it.

The success of GraphQL is kind of downstream of that, because once you had this whole React thing, you knew what the front looks like and could work backwards from there. It's about saying, let's start thinking from the query and build everything around that. So it's about starting from the front-end dev's mental model and going from there.

00:04:52 - Ben Edelstein

Got it. And before we dive into GraphQL, is Relay really a framework that uses GraphQL, or was it just a similar architecture? Maybe a quick introduction to Relay, because I think some of that history is interesting.

00:05:04 - Anthony Campolo

Yeah, and this is a really good question because Relay kind of sits between the React stuff and the GraphQL stuff. GraphQL itself doesn't really have anything to do with React or even with JavaScript. So let's talk about that.

This is a specification of how to get your front end and back end to agree on a schema and agree on types. That's what makes it really unique, because you could agree on those types with a Go backend or a Java backend just as well as for a Node/JavaScript backend. You can do that translation, and what Relay was doing was handling the client-side cache. There's a lot around caching and normalization that goes along with this.

The thing that made Relay really cool is that it translated from GraphQL to React speak. This is where the historical stuff comes into play, because they were all designed together and they fit very well together.

00:06:26 - Anthony Campolo

That's why React and GraphQL fit very well, because you have this Relay piece that fits it all together. But they're not technically coupled technologies. There's this weird question of how this all fits together, like do they require each other? They don't. But they kind of do, because they should philosophically fit together. It's this whole weird, like, which of these pieces do I actually need? Which don't I need?

00:06:52 - Ben Edelstein

Yeah. It's almost like React and Redux. They're coupled but not necessarily coupled. But you kind of need a state management layer for React, and same idea here. You have GraphQL, but you do need something to couple it to your view layer, and I guess Relay solves that problem.

So looking at GraphQL, we've mentioned types and schema and the ability to request just the data you need. Could you give an overview at a high level: what is GraphQL, how do people use it, and how does it help?

00:07:31 - Anthony Campolo

Yeah, I think if you're a developer, the way to think about it is very simple. You can think of it like a JSON object with just the keys and no values. It's nested objects within objects. You see an object in your curly brace, and you have an object in that curly brace. That's why it's really simple to write.

You would say, okay, I want to get movies. So you'd write "movies", then parentheses, and inside that you have, I want the name of the movie. It's about having nested queries inside each other, but it's always a query inside another query. It's very recursive in that sense, and that's what the query language is optimized for.

If you just look at a query, it's very readable. You say, I want this, and I want these things from that item or object.

00:08:36 - Anthony Campolo

It's really nice because going back to the schema and the types, you always have that available for your GraphQL server. You'll frequently hear people compare GraphQL and REST. One of the things you'll hear talked about is that you only have docs for a REST endpoint if someone sat down and wrote them. With GraphQL, you're always going to be able to see, okay, what is this actual data like? What are the things on that data that I can get?

You don't have to think about how to write the query to get that, because GraphQL has a standardized query language for you. You can learn this standardized query language that then allows you to interact with any GraphQL server you want because we have these agreed-on specifications.

00:09:24 - Ben Edelstein

And so would it be accurate to say that with GraphQL, whereas with REST you have a whole bunch of endpoints for each type of data you want to request or send, with GraphQL you have one endpoint. Based on that JSON valueless object you send, you can request just the data you want in the shape you want. Is that accurate?

00:09:46 - Anthony Campolo

Yeah, totally. There's the query and then there's the endpoint. GraphQL is great because it simplifies it to only a single endpoint, so you always know exactly where you need to send the query. And because you have this standardized query language, you just have to know what the schema is, and then you can figure out how to send that query.

00:10:10 - Ben Edelstein

I'm curious to hear more about the idea of docs being generated automatically based on the schema, because that's certainly one of the challenges with REST. And having used GraphQL, one of the things I love about it is GraphiQL, basically the tool for introspection of a GraphQL API. Could you speak a bit about that?

00:10:33 - Anthony Campolo

Yeah. You hear them called GraphQL explorers and GraphQL playgrounds as well. I want to start by saying I hesitate to refer to them as auto-generating docs. I actually think auto-generating docs is an oxymoron, because docs, by definition, have to be written by a person. That's the only way they'll actually make sense.

But it gives you the closest you can get to auto-generated docs, in the sense that you can know at least what you can actually do against this: can I write to it, can I read from it, can I update it? That kind of thing. It bakes that into the schema. That's what's really cool about it, because you're allowed to take any schema from any other GraphQL and modify it for your own needs, because you can always see the schema.

This is what I mean about being kind of auto-generated: you have this graphical playground thing. I would recommend people go to Rick and Morty slash GraphQL. I think that's what it is. If you Google that, you can find that endpoint. That will take you right to one of these GraphQL editors.

On the right you'll see docs and schema. You can click those and play around. I always start people off with an endpoint like that so they can start querying it and getting the data back and see how to look at the docs and make the query. That is a really good way to get people's hands on GraphQL and break down all this crazy abstract stuff we're talking about. It brings it down to the level of how do I interface with this, how do I write queries, how do I get data back? It's like Postman or Insomnia, these API client tools that a lot of us as developers know really well and leverage.

00:12:18 - Anthony Campolo

It sits at a weird intersection between something like that and a full-fledged front-end framework.

00:12:25 - Ben Edelstein

Tell me a bit about posting data. In a REST API you can do a POST request. In GraphQL, I think it's a mutation. What does that look like, and what are some of the ways that GraphQL mutations improve upon POST requests in a REST API?

00:12:44 - Anthony Campolo

You don't necessarily want to think about all these working the same way in the REST world because in GraphQL you only do POSTs. What I mean by that is anytime you're sending something to the server, it's going to be a POST. You're not going to do GETs or PUTs. The reason is because you have the schema, the language, the GraphQL. The whole thing exists, so you already have it baked into the language in terms of actually writing the word "query" or the word "mutation" before you do a thing.

Some people may have heard the term CQRS, command query responsibility segregation, which is about separating your commands from your queries. If you just change command to mutation, and keep query, that's kind of what we're talking about here. I think of it as the query is getting data, so reading, and then anything else is a mutation.

00:13:52 - Anthony Campolo

Creating is a mutation. Updating is a mutation. Deleting is a mutation. With GraphQL you basically say, okay, I'm going to write a query, so I want to get this data back, or I want to create. Then you have an input of what you want to feed it, so you can do arguments. The whole CRUD is baked into what GraphQL is itself.

00:14:15 - Ben Edelstein

Got it. And kind of below the GraphQL layer you have whatever data store you're using, generally assuming there's a database backing your application. I'm curious, when you're using a SQL data store, what are some of the synergies with GraphQL, especially with regards to maybe type safety of your query? And particularly, we've talked about Prisma on the show before, so curious to hear you explain some of those integrations between GraphQL, Prisma, or SQL.

00:14:47 - Anthony Campolo

One of the things people really like about GraphQL is that it is very much a mediator between the front end and the back end. It's not tightly coupled to any sort of database technology, but it does work very well with SQL. Going back to this whole historical thing, Facebook was well known for being the LAMP stack, and they had this whole stack they were using as their back end. That's kind of what ended up being translated into this GraphQL thing.

With Facebook, you had this way where you could specify the endpoint, specify the types, and then do a lot of nice introspection into that in terms of generating stuff with the types. It's kind of funny because it goes back to this: they had their own typed version, an extended version of PHP called Hack. They had all these other language extensions that ended up turning into what we now think of today.

00:16:03 - Anthony Campolo

But going back to it being a middle layer, it doesn't necessarily have to be SQL or NoSQL. It can be either. That's where Prisma comes into play. Prisma is an ORM. They had a long soul-searching over whether they call themselves an ORM or not. I think you can talk to Nico about that. They eventually decided that people know what an ORM is. It's a tool that kind of makes sense to people.

Prisma became the mediator between your front end and your back end at the database level. Then Prisma decoupled themselves from the GraphQL stuff. That's where more history comes in and it gets confusing and hard to get into, so it's not really that important.

Prisma used to be entirely wrapped up with GraphQL and then was extracted out of GraphQL and became just this database thing. So with, say, RedwoodJS, they handle the schema. You write your GraphQL schema, then you also write your Prisma schema, and that's how you keep those two separate. This is what allows these tools to become a lot more decoupled than they used to be.

If you want to bring in a whole Postgres backend, you can do that with Prisma. If you want to switch it to, say, MongoDB with NoSQL, you can do that as well. That's really amazing and hasn't been something you could really do with an ORM tool in the past.

00:17:41 - Ben Edelstein

Got it. Yeah, it makes sense. In terms of some of the terminology that someone getting started with GraphQL might want to understand, we talked a bit about schema, queries, mutations. There are a few other words I think of, like input types or interfaces or concrete types. Could you go through some of those and what each means?

00:18:02 - Anthony Campolo

Yeah. They want GraphQL to be extensible itself because they want it to be a full-fledged language in that respect. So you have all these ways of typing it. This also gets into the whole JavaScript versus TypeScript debate and what you get out of typing. The real thing is you get a lot of nice developer tooling around it. You get nice autocomplete and error messages when you have a project that's type-aware. There are a lot of good downstream effects.

That's why you want to have your data, your database, be typed. You'll have those types flow from the back end into the front end. That's where GraphQL is really nice in terms of agreeing on the types as the front end and the back end. Once you agree on the types, you can start building all this tooling around that.

00:19:05 - Anthony Campolo

We talked about the graphical editor. You can take that a step further: not only do you have this really nice editor where you can write queries, you can actually have a click and drag-and-drop kind of thing where you can just start clicking stuff and it'll write GraphQL queries for you and put things in the right places.

00:19:24 - Ben Edelstein

Got it. So to take a step back, I'm curious to hear a bit about your journey and what led you to becoming such a passionate GraphQL expert. Maybe you could tell us a bit about how you fell into this world.

00:19:40 - Anthony Campolo

Yeah, it's a long and winding story, but the kind of TL;DR is that I was originally a musician. I did a lot of music teaching and worked in performing arts environments, and did that for, let's say, about half of my 20s. I started as a music teacher, then I ran a performing arts summer camp called Youth Camps for a couple of years, and eventually decided I wanted to get into a job that would be more creative, like the arts, but also more tech-focused and would have a harder skill set associated with it.

I ended up trying to learn data science and machine learning type stuff. This was back when deep learning was first coming out, DeepMind was a big thing, and AlphaGo and all that. I didn't really get a lot of traction there, and I realized that if I wanted to be able to get a job I needed to learn web development. Everyone just kept saying, especially React, is going to be the thing to learn.

So I pivoted to the web dev, HTML, CSS, JavaScript world. I started going to Lambda School, and Lambda School was in the news recently. These days it's a very controversial income-share agreement school where you don't pay anything before you start the bootcamp, but you sign a contract where you pledge a certain percentage of your income for two years after you get a job. The idea is that you don't pay a dime until you already have a job, and then they get a cut of your income.

00:21:43 - Anthony Campolo

So I did Lambda School and learned a lot of React and modern JavaScript. As I was doing that, I started learning about RedwoodJS. RedwoodJS is the linchpin of a lot of these things and how I got into GraphQL, because it fit a very specific problem set I was learning at Lambda School: how do you build a full-stack React project?

There's a nuanced thing there because you have this single-page application talking to your backend, which is going to be some sort of Express server connected to a Postgres database. You have to figure out that whole data flow and how to manage the auth and all that.

Redwood was a framework that basically said, hey, we solved all this for you. It was very much a convention-over-configuration idea. It's very opinionated, as people say. We can direct people to the actual Redwood episode to get a taste of all that.

I used it and immediately got it. I was like, this is really cool. I was using GraphQL without really realizing it, because in Redwood, GraphQL is the whole deal. Your front-end React app is making GraphQL queries directly into your backend, which is a Postgres database. You create this GraphQL server and GraphQL client and have it all contained within a single project, and you get that out of the box. You don't have to figure out how to wire it all together.

You can have generator commands that spin up interfaces for you really quickly. Going back to the nice tooling and stuff that goes along with this, once you build up these layers of abstraction, you suddenly have this super powerful framework that you didn't have to do anything to get.

00:23:48 - Anthony Campolo

You just have to understand what GraphQL is and how to use it in the mental model that goes along with it.

00:23:53 - Ben Edelstein

I'm curious, as you pointed out, there's a lot of controversy around Lambda School, so I'm curious to hear about your experience. It sounds very positive, but would be interested to hear how you felt the program was and whether it was valuable and something you'd recommend to others.

00:24:09 - Anthony Campolo

With bootcamps, it's always hard because you can't give blanket advice. Everyone's situation is unique and contextual, and it's hard to say what's actually right for someone as a general case. I do think Lambda was good for me. I do think that I owe Lambda a lot in terms of me getting where I am.

I hesitate to give them too much credit because I essentially ended up dropping out of Lambda to do Redwood instead. In retrospect it worked, but at the time it would have seemed like a really bad idea. It's really good if you don't know what direction to go and you need someone to point you in a direction.

For me, I had to find something that would allow me to work on code with senior developers. That was the biggest thing with doing something like Redwood: you get to be in the thick of it in a way you can't in a bootcamp. You're seeing high-level discussions that you don't fully understand because all these words are thrown around that don't make sense to you. But as you listen to these conversations over months, if not years, things start to click and make sense.

So if you're interested in bootcamps, you want to research what's available and what the different financial obligations are. Then you want to ask to speak to people who have been to this school, who have gone through it, so you can get their honest opinion. That's the thing that makes it hard.

00:26:04 - Anthony Campolo

Because it's set up to be free so basically anyone can do it, they have to set up the system in a way where they know half the people going through it aren't going to make it to the end, that they're going to give up at a certain point. They need to have that be an option while also not letting it detract from people who do want to stick it out till the end. There's no good answer for that.

That's why you end up with this huge churn and rounds of layoffs and things like that, because you're constantly iterating and trying to figure out how to do this. No one has ever done this before. It's not easy, and I think people have a hard time cutting some slack in terms of what they're doing and how hard it is.

At the same time, they're not perfect, and you can't act like these things are perfect when they're not, because these are people's lives you're messing with, and you're giving them advice about whether to go to these bootcamps or not.

00:26:53 - Anthony Campolo

So I can't give a simple yes, this is a good or a bad bootcamp, or yes, you should go or not go, because there are too many considerations. But hopefully knowing what those considerations are can help people out.

00:27:08 - Ben Edelstein

So this week we have a couple of listener-submitted questions. This is a new segment we're doing where we reach out to our audience. We say what the topic of the episode will be and people submit questions.

The first one I have here is: what are the most exciting new things that are coming to GraphQL this year that people should be on the lookout for?

00:27:29 - Anthony Campolo

There's always going to be new things coming out and new things in the scene. When I look at the whole ecosystem of GraphQL, I think of the open source world and the software-as-a-service corporate world. I find that almost everything that's interesting is more of a bottom-up, open source-focused way, and that has downstream effects in terms of the types of products we use.

I would point people to this group called The Guild. It's a really fantastic group of developers who have their own unique decentralized model, where each individual contributor owns the repo of whatever project it is. They have all these different interlocking tools that make up this greater suite of GraphQL tools. They've got a lot of things coming together around things like GraphQL Helix and Envelope.

00:28:43 - Anthony Campolo

There's a controversy over how that is being said, and that's some of the stuff I find really interesting: how do we expand beyond these base GraphQL libraries and frameworks that everyone knows about? Most people are introduced to GraphQL through the lens of one of these specific tools or companies, whether that's Prisma or Apollo or whether it's Hasura or any of these companies. That's usually the entry point, but there's a lot of cool stuff happening among the different libraries and ways of working with GraphQL.

I would point people to things like GraphQL Helix, GraphQL Shield, and GraphQL Mesh. There are a lot of cool pieces of technology.

Going back to when I mentioned how I worked on Redwood on the core team, that eventually led to a job with this company called StepZen. StepZen is a company for creating managed GraphQL API gateways, and it sits at this cool intersection between things like databases and REST APIs.

00:29:58 - Anthony Campolo

You can turn a database schema into a GraphQL schema, but you can also turn a REST endpoint into a GraphQL schema. This is what you can do with something like GraphQL Mesh. So expanding out to the GraphQL is eating the world idea is that you can start with GraphQL and then have that expand out into all these other areas, and how do we do that translation to wherever we want it to go?

00:30:27 - Ben Edelstein

Next question is, who should people follow to get the latest and greatest about GraphQL? I think that speaks to a general thing I hear from a lot of folks in the front end world: things move so quickly, and how do you stay on top of new developments or tools?

Twitter is certainly one good place if you know who to follow. So maybe we'll scope it to that. Any recommendations of who to follow on Twitter to stay on top of GraphQL stuff?

00:30:56 - Anthony Campolo

Well, I am definitely aggressively on Twitter. So if you want to know about GraphQL stuff, you can follow me and I'll get you a pretty decent chunk of it. There's a great newsletter called GraphQL Weekly that's done by, I believe, the GraphQL Foundation. That's a really good one that I recommend people check out.

If you look to people who've been around the scene for a while, people like Uri Goldshtein or people like Sean Grove are always good sources for this stuff, and it is a very open source-focused tech. You'll find a lot of people who are out there talking about it and doing stuff with it.

I think you're going to have a hard time figuring out who the specific thought leader is you want to be following, because it probably depends on what your philosophies around GraphQL are going to be. Even within GraphQL itself, there's still not really broad consensus around certain things.

00:32:00 - Anthony Campolo

So I would say things like GraphQL Weekly, and then trying to figure out what the actual GraphQL projects are, like what has the most stars and what doesn't. Do stars actually matter or not? That's its own question.

But if you just keep your eyes up and listen, especially to podcasts like this one, I really can't stress how important listening to podcasts is. I've listened to this podcast since you guys started. I was really happy when you started doing it because you're interviewing so many of the same people and talking about these same types of conversations.

There's never going to be just one person to follow because you have to figure out a way to follow the sum total of the conversation. The only way you can really do that is by being a fly on the wall of lots and lots of these conversations.

00:32:49 - Ben Edelstein

What is the best place to start when you are hoping to learn GraphQL?

00:32:54 - Anthony Campolo

Yeah, there's actually a pretty good onboarding experience.

00:32:56 - Anthony Campolo

You can just go to GraphQL.org, and they have a total-beginner, from-scratch GraphQL 101 explaining all the stuff we've talked about. I really recommend starting here when you're explaining this to someone or just sending people here when you want them to learn about it, because they can visually see the query and the code.

All this stuff we're talking about is very abstract, and you can try to talk about it. But if you actually show someone the code, that's what makes GraphQL really nice. The code is simple, concise, and readable. You can show someone a query and the response you get back from that query. It usually clicks immediately, and it's like, okay, cool, I get it.

So if you go to GraphQL.org, that's the very basic kind of hello-world starting point. Then the docs get you a little further in terms of showing you how to start to make a GraphQL server and all that.

00:33:53 - Anthony Campolo

I would then point people to How to GraphQL. It's a great site that has larger full-stack tutorials. It'll show you how to do the whole integration between the front end and the back end because there's going to be multiple layers to this in terms of how deep you want to go. There are always going to be two pieces to it: the front end piece and the back end piece.

There's going to be a GraphQL server and a GraphQL client. Whether you want to own that whole space yourself or just want to own the front end or the back end will dictate what you need to learn and where you want to focus your time. It's cool because it maps very well. If you're a front end or a back end dev, you'll be able to find a place that fits and makes sense with GraphQL, because there's still that separation between what is the front end and the back end.

00:34:51 - Anthony Campolo

That's what makes it nice, because then you have a unified understanding of how your front end and back end should talk together. That's where you avoid all this REST API-ness.

00:35:04 - Ben Edelstein

What are some common misconceptions about GraphQL?

00:35:07 - Anthony Campolo

Yeah, I think the biggest misconception is that it's this really fast-moving, constantly breaking, cutting-edge kind of piece of tech situation.

00:35:09 - Anthony Campolo

Actually, all of that happens around a very stable core because it's a spec. It's important that people understand the difference between something being a spec and something being an open source library.

The difference is that there is a specification where they've written down what it means to be a GraphQL server, what actually goes along with that, and what the requirements and restraints are. You can follow the GraphQL spec, and you never have to use any of these tools or libraries that we've mentioned. You can create it with a Ruby on Rails backend and hit it with vanilla JavaScript from the front. You don't need to use a GraphQL client or a JavaScript library at all.

That's what I like to get across to people: it's actually a very simple and basic model, and then you have all these other things built on top.

00:36:28 - Anthony Campolo

So you want to first really get a handle on what GraphQL is before you start getting into GraphQL frameworks and GraphQL companies and how all of that fits together. That stuff can come later. Once you understand what GraphQL is, you start to understand what problems come along with it and how each of these companies and projects address that within the framework of what GraphQL is.

00:36:52 - Ben Edelstein

And finally, this is not a listener question, but this is a question of ours outside of GraphQL. What are you most excited about in the world of front end?

00:37:01 - Anthony Campolo

I am really excited about this whole new front-end build tool thing that's going on. People may have heard of esbuild, they may have heard of Snowpack or WMR or Vite. These are tools meant to either expand upon or replace things like Webpack and Rollup, which are your bundler-type tools for people who write a lot of JavaScript.

The way we write JavaScript these days is that you write your JavaScript project, and you take that whole project and run it through all these crazy transformations, through build steps and compilers and all this stuff, to have that be something that can actually be shipped to the browser. This has been a step in the chain that's gotten more and more complicated over the years. It's why when you develop, your computer chugs and you hear your fans going nuts and it takes forever to do anything, because Webpack is run over and over, the build is compiled, 10,000 files do all this ridiculous stuff.

00:38:11 - Anthony Campolo

These tools are about how do we rethink all this from first principles and not use JavaScript to do everything. The killer idea is: why don't we write JavaScript tools in not JavaScript? So esbuild is written in Go, and you also have these Rust-based libraries coming out as well.

You see these now being adopted by things like SvelteKit. SvelteKit was originally using Snowpack and then switched to Vite. Now Vite is being picked up by Nuxt and esbuild is in Remix. Esbuild is also in Redwood as well.

The transition is already happening in a way where most people aren't really going to realize that it has happened, and it already has for the most part. If you're someone who finds this stuff interesting, now is the time to dig into these tools, learn about them, and gain some expertise because they're going to be in everyone's tools very soon.

00:39:15 - Anthony Campolo

No one's going to know how to use them.

00:39:17 - Ben Edelstein

Well, Anthony, thank you so much for coming on the show. Really enjoyed the conversation today. We will put links to a lot of the things we talked about in the episode description. So if you want to check out some of the things Anthony talked about today, that will be there. Thanks again, and hope to have you back one day in the future.

00:39:37 - Anthony Campolo

Yeah. Thanks so much, Ben. I've really enjoyed the show as you guys have been putting it out. I really enjoyed the content on LogRocket in general. I'd been reading your articles for a while. I think it's some of the most fantastic content anywhere online for dev content. So thank you for doing everything you do, and happy to be here.

00:39:55 - Ben Edelstein

Well, thank you. We really appreciate that.

00:40:07 - Ad VO

Hi. Thanks for listening. Please remember to like, subscribe, email me if you want. Even though none of you do, go to LogRocket.com and try it out. It's free to try. Then it costs money. We'll see you next time. Thanks.