All right, hi everybody. My name is Kirupa, and I'm here with Jamie Barton, and we're going to talk about the exciting world of GraphQL. So, JB, tell us a little bit about yourself.

Hey, yeah, thanks for having me. It's great to chat with you about GraphQL. I mostly work in developer relations, which covers a lot of different things, but primarily I spend a bunch of time showing people how to work with APIs and get the most out of them. I also relay useful feedback to product teams and experiment with new ideas and stuff. That's primarily my role now across multiple companies. I have a pretty varied background in programming. I started out with Flash and ActionScript way back when, slowly migrated to PHP, and found myself using Ruby on Rails.

Then, over the last five years or so, I've been working a lot with GraphQL, JavaScript, and Node. Js, building full-stack apps, client-side and backend code, serverless functions, and all that fun stuff.

That's quite a transition, from Flash all the way to pure backend. Did you ever make that stop in ColdFusion, like so many people did back in the Macromedia and Adobe days, or did you skip that completely?

Yeah, I looked at ColdFusion a little bit, but I skipped it. When I was using PHP, I started working with some of the PHP ecosystem, WordPress and things like that.

Nice, nice, nice, nice. So tell me about GraphQL. What is it?

What an amazing question. I think the definition of GraphQL has changed a lot over the last few years, certainly as more people have found different ways to use it. When it first came out, it was this thing where you could make a request that reduced overfetching and describe the data you wanted, and you'd get it back in JSON. So you could say, okay, get me a blog article, or get me all blog articles and their content and author, but only get me the author's name and maybe the author's avatar. You could also say, in that same request, I want the blog author's related articles that they've written previously.

You could describe all of that in one request and get the data back without having to go to the API and say, okay, get me this resource by ID, then get me related resources, and kind of have all these different REST endpoints. You end up with one GraphQL schema that describes your data, and then you can ask for it. That pretty much still exists today. That's what GraphQL does. The one thing I think has changed is that it's not just one API we're working with today, it's multiple.

There are tons of different ways you can federate data or schema-stitch data, bring all of these different sources together, and have one entry point or gateway you can make all of these requests to. So you could be fetching data from one service in one request, then make another request and fetch it from maybe three or four different services together. GraphQL will handle all of that at what you'd call the resolver level. It's changed a lot. The way I heard someone describe GraphQL recently was as a feature-rich specification.

GraphQL itself isn't really a thing so much as a specification that says, okay, this is how you describe your data and this is how you can go about connecting nodes and various things. But it's a feature-rich specification that isn't really bloated in any way. The specification actually moves relatively slowly, and that's good and bad. It can frustrate people because they want to see new things added all the time. But as you start to add stuff, you add bloat and solve problems that exist today but maybe aren't necessarily going to be around forever.

Then you end up adding a lot of tech debt without having consensus on what should or shouldn't be added. The GraphQL working group is fantastic about that. They look at proposals, go through them rigorously, and discuss: should this be in? What advantages does it bring? What does it bring that's maybe not too good? I love it for that reason as well. It's a real community, and I could go on. There are tons of other things.

That was a great overview of GraphQL and all the things it brings. In many ways, it seems like if I'm building an ecommerce site and I need to fetch product information, pricing, and things from multiple locations using a REST API, I'd make multiple calls. I'd probably say, get me all the items I need to display, then get me all the images if they're coming from a different service, and maybe some metadata about what's going on. What I might display is only about 20 items. But I may get back 100 items with 200, whatever the API decides by default, which means I'm sending unnecessary data and making the payload larger.

With GraphQL, I can fine-tune my request to get exactly the thing I need. I don't have to make multiple requests. I can send one request and say, I'm doing exactly this, so send me exactly what I need to render the content in whatever form I need. Did I summarize that correctly?

Yeah, that's all correct. I think the biggest difference between REST and GraphQL is that GraphQL itself is just a specification, like I mentioned before, so it can be delivered over whatever transport layer you need. The most common and popular one is HTTP, so you can deliver GraphQL requests over HTTP. GraphQL itself just takes in a request, passes it to the data layer, executes it, and returns something. Whereas with REST, there are specifications like JSON: API and many other attempts. With GraphQL, that's just what it is: this is the specification, and everything else kind of emerges from that. SDKs for your front end can be automatically code-generated out of the box.

You don't need to do something special to make your REST APIs work with them. That's really nice. And types are at the core of GraphQL as well. The type system matters a lot.

Nice. So essentially that means there isn't something brand new from a traditional transport-layer perspective that we need to invent to use GraphQL. If you're using things like the Fetch API on the web, or more complicated request APIs in native applications and other formats, you can still use that. The implementation of GraphQL on the server just needs to match the specification, and then the right behavior will happen. So if I understand it correctly, a lot of the querying logic almost lives in the client, and then the receiver on the server takes that, processes it, and gets the right results back.

Yeah, that's right. You have a client-side application that makes a request, and the server can figure out what it needs to do to get that data and return it to you. There are some trade-offs with GraphQL and, you could call it, the HTTP transport spec. One of the biggest things is error codes. GraphQL often returns 200 OK for errors, and that freaks a lot of people out when they're coming from REST to GraphQL, because they think, this doesn't behave like what I'm used to. What I keep telling myself, and others I have this discussion with, is that GraphQL isn't REST.

It's not based on the traditions you might be used to. It's something entirely different, so try not to draw too many comparisons. These are two different things that are both well established, and they can be used together or independently of one another. I wouldn't say GraphQL is better in every way, and I wouldn't say REST is better. It really comes down to the implementation. Going back to what you were saying before about the comparisons with REST, I often hear this burger analogy, and I might mess it up a little bit.

REST is kind of like a burger where you ask for a burger and you get everything, and then you take what you need from it and kind of make your own burger, pulling bits out like the gherkin or something. With GraphQL, you can say, okay, get me a burger with a patty, some cheese, some sauce, but don't give me tomatoes or lettuce or anything else. Just give me what I want. That's kind of the rough idea of that burger analogy.

I think what you're saying is that with GraphQL you basically get a custom order, and with traditional APIs it's more like you get what you get and it's up to you to post-process it. I guess in some way that works. Actually, I like that burger analogy, so let's take it further. Let's think about a fast-food chain. They're fast food because they often have one prescribed format for the burger, so they can make it over and over again and get it to you very quickly. With a custom order, you can't have that same muscle memory.

You have to look at each order in detail, make it each time, and carry it forward with whatever specification the customer asked for. So in the HTTP world, I'm guessing that has implications for things like caching and CDNs. If you have a burger that always works the same way, you can be pretty certain that every 24 hours maybe I refresh my cache, but there's going to be that burger every time someone requests it. With a custom order, you can't really assume it'll be the same. Does the same idea apply with GraphQL versus the traditional approach?

Yeah, caching is interesting because it can be done in many ways with GraphQL. Since most GraphQL requests happen as POST requests, you lose some of the browser's built-in caching behavior, so you have to turn to other alternatives. One of the easiest is to use a service that's basically a GraphQL cache. There are a lot of services that do this. You give it your source URL, schema, and endpoint, and it becomes a new gateway that your requests go through. It takes in the operation, and that operation in GraphQL could be a query or a mutation.

If you imagine a burger as the type and the different fields as the patty and whatnot, it can take that whole order, kind of jumble it into one string, check whether there's a cache key, and then pair the response with it once it's executed. That's pretty much how that works from a caching point of view when somebody else is doing it for you. You could implement all of that yourself as well. There are a lot of tools you can use. There's a GraphQL plugin ecosystem called Envelop, and there's a plugin in there called useResponseCache. You can install a plugin like that into your Node.

Js project and get this kind of caching behavior out of the box. That setup is something you can choose to run and maintain yourself, then extend it. You could store that data in Redis or wherever you want and handle all of that cache yourself. If you want to invalidate it, you've got direct access to do that through the plugin or through Redis itself. One other interesting point about caching is that if you're building a static site, you might not need it at all. If you're outputting a static HTML site with a framework, caching isn't going to be your biggest problem.

You may have one burst of many different requests happening to build all of those pages, but then those pages get cached on the CDN at the edge, so your API may never get hit again. Caching can be mitigated that way. Also, if you're interacting with GraphQL on the front end using something like urql or Apollo Client, which is quite popular, you get client-side caching behavior too. As you make requests to a GraphQL API, querying and mutating, if you send a mutation to update your comment on a blog post, you can configure those clients to understand that a change has happened.

GraphQL knows the type, the ID, and the field that changed. So you can optimistically update that and then update the client-side cache so it no longer needs to go back to the server to get the data. That's built into pretty much all GraphQL clients as a common behavior. People implement the caching mechanisms and storage differently, but the idea is the same: you mutate something, and it updates the client-side cache. So when you switch around pages and come back to it, that comment is in the same state as where you left it. And obviously you can change that.

You can say, okay, when I go back, maybe it refreshes because it's past a certain interval. Or maybe if you go away from the page and come back to the tab, it refreshes automatically. There are tons of different things you can do. Caching is very interesting, and there are many ways to solve it. It's a question that comes up every single time someone talks about GraphQL or considers using it, because people see that it doesn't use the browser's default behaviors and think it's the end of the world, when it really isn't.

Yeah, and I agree. In all cases, you have some data somewhere, usually a database or some other system. There's always a middle layer between the client and what happens to the database. There's always something running in the middle, and I think you mentioned Apollo as one of those things. That intermediary on the server takes the request, does the right things, and gets the data back. Then the caching can be done on the server itself so the same request doesn't have to go to a much slower database instance. You just get the cached version directly and then send it back to the browser, where the CDN can kick in.

And there are plugins that simplify a lot of that, so the behavior people expect can still be fully retained. So it's almost a case where, yes, you're doing a custom order, but if you're tuned appropriately and the restaurant is optimized for custom orders just as efficiently as it can do static, non-custom orders, the end result is that you get the same benefits as someone ordering a pre-made, preconfigured burger. That's really cool. So if I have a more traditional non-GraphQL API, how much effort would it be to migrate to GraphQL?

This is a really interesting question because so many tools have emerged over the last few years for exactly this reason. Many companies want to leverage new APIs that are GraphQL-only and connect them with their existing APIs. As I was talking about earlier with federation, schema stitching, or meshing together different services, there are a lot of ways to migrate. You could create a GraphQL server that talks to your REST API, and that sounds a bit weird. It means you've got two middleware layers, but inside the resolver you can handle the communication. That could be done as fetch requests, through gRPC, or through some other mechanism.

If that code is living closely together or hosted together, it's not as bad an idea as it sounds. I've seen that a lot. I've done it myself when getting started and trying to persuade a team to move to GraphQL. Because of the client-side benefits and the developer-experience benefits, building a GraphQL API that lives on top of your REST API is often one of the best ways to get started. I also want to mention GraphQL Mesh. It's a library that builds artifacts you can send requests to, and it has many different source adapters.

You can specify in the configuration, this is my GraphQL endpoint, and it will just merge that in as normal. But you can also say, here is my Swagger file, and it can automatically generate the GraphQL types and handle the requests to the REST API for you. That can act as the mesh between different APIs. That's probably an easier way today if you don't want to create a server, host it, create the types, and hook up all the resolvers. With something like GraphQL Mesh, you can add these different sources. You can even specify something like a Mongoose model and it will generate the types automatically. It's really impressive.

I'd say that's probably one of the easiest ways to migrate. Obviously, the hardest part is convincing your team, your boss, or the PMs that you now need to build a GraphQL API, because quite often you can't just rebuild an API from the ground up. You're probably going to need tools to bridge that gap until you can. So there are many different ways you can go about it.

Yeah, absolutely. And being a PM, I can absolutely imagine that conversation. It's going to be a change in the endpoint. You need to maintain the legacy one for a bit so existing customers don't have a broken experience, especially if it's a non-web app where people have to go update a binary. There might be a lag between when an update happens and when it lands, so the layering approach is actually very nice. In the back of my mind I'm always thinking, do we now maintain two parallel systems?

If we need to make an update or manage the behavior of the API, do we now do it twice, once for legacy and once for the new one? But from what you're saying, by having it be layered, you're still making a change more fundamentally in one location, and it just propagates to whichever endpoint it is, GraphQL or not. You still get those benefits. That's actually really cool. One of the other interesting things you touched on at the very beginning is the ecosystem and the community around it.

Even during our chat right now, you've mentioned a lot of different names for services, products, plugins, and technologies that interface with GraphQL to solve common problems. That's really great to see, because when you're doing something brand new, you always wonder how much you have to reinvent and how much you can just use off the shelf. It sounds like the off-the-shelf support is pretty good for almost 99 percent of the common use cases.

Yeah, community is a huge thing with GraphQL, and it has been since the beginning. When GraphQL was first announced, there was a GraphQL conference, and that conference grew in attendees year on year. I think it doubled or tripled every single year, which was fantastic. It showed how many people were interested in GraphQL or working with it. There were more speakers, more talks, more lightning talks, longer talks, and more dev talks, including talks about using GraphQL in production only a year after it had been announced. That was stuff we were seeing in the early days, and it's only gotten better.

Now there are more people talking about it, more people integrating it, and more people with stories to tell about things that worked and things that didn't. That's really good. But there's also the open-source side of things. One of the things I love about GraphQL, and I'll say it again, is the type system. That's what it's fundamentally built around. It lets developers get the AST of GraphQL, the shape of a request, or the shape of a schema. You can introspect your GraphQL schema, and all of this is built in, which is phenomenal.

You can get everything you need to know about your GraphQL API, and then developers can build tooling around that. Whether it's building schema programmatically or creating an SDK automatically through code generation, you can say, okay, go get my GraphQL types, look at the GraphQL requests I'm making, and make those types safe. So when you're working in your IDE, you get immediate type safety and feedback. When you're typing out a JavaScript map to iterate through your comments and you type comment dot, it can show name, author, URL, or something like that, and only show what's typed.

That's just fantastic developer experience, and for a lot of people that's a real wow moment. Once you start doing things like that with GraphQL, it's amazing. And the community comes together to share great ideas and build great projects. There are so many people doing that in the space.

And I think, just like we saw with the growth of React, Facebook, now Meta, was the originator of it, and they used it for a lot of their complex scenarios. So it's often built from the ground up for things that may happen to feel simple on the surface, but we know it scales to extremely massive workloads. GraphQL seems to be following a very similar path. I think it was used internally first to simplify the massive amount of data a typical page on Facebook might generate. That gives it some validity if you're going to bet on something that we know has been used extensively in real-life scenarios.

Yeah, definitely. I often hear this comment around GraphQL that it was built by Facebook, which had a lot of problems when it came to consuming data and all of that. The size of problems Facebook had are probably way bigger than you will ever have, so a lot of people say, well, why even bother using GraphQL? But once you start looking at the community, the SDKs, the code generation, and the different tools to stitch, federate, bridge, connect, and mesh this stuff together, that's why I would use GraphQL over something else. All of that combined gives me a really great developer experience, and that kind of trumps everything else, in my opinion.

I guess I have to ask then, GraphQL seems really awesome. Is there any reason why someone would not want to use it? Are there use cases where it really isn't great and you shouldn't use it for those purposes?

Yeah, there's probably a ton. The immediate thing that comes to mind is something like a health-check URL. I probably wouldn't spin up a GraphQL endpoint just for delivering, yeah, I'm good, for a health check. That's a bit of a silly example, but that's probably one case where I wouldn't. Also, if you have endpoints that you just want to send data to, you can continue to use REST endpoints alongside GraphQL. I've done this myself when submitting analytics data, or that kind of thing, when someone likes a video or views a video page. I really don't want to maintain a GraphQL server for analytics.

Out of the box, it does take a bit of time to design a schema that scales, so there is more time you need to invest up front with a GraphQL API. So if you're building something that's just a proof of concept, or doesn't require you to accept much data or query too much data, then GraphQL may be a bit of overkill for that use case. But if you do have the time to design a GraphQL API and build it, I'd probably say the developer experience and the code-generation side of it would reduce time in other areas of your project. It's a fine balance.

It really depends on the project you're building. Certainly if you're working on a team project, GraphQL can be really awesome for the reasons I mentioned.

That sounds great. Is there anything else about GraphQL that you feel the audience should know that we didn't cover?

Yeah, nothing else really comes to mind. I just think if anyone listening is curious about GraphQL, there are some really great resources to get started. There are a lot of articles online from the different companies providing GraphQL, and I'd say just get stuck in and build something. There are also many hosted GraphQL APIs, so you don't have to worry about building the server, because that can be a really daunting thought when you're getting used to GraphQL for the first time. There's the server aspect and then there's the client. I'd say, okay, pick the server or pick the client and just learn one side of it first.

For many years, I was just building GraphQL APIs and not consuming them. Then in the last few years, I've been consuming them but not building them. So just pick one side and get going. It's always going to be great to know how both sides work, but that's what I would do.

That makes a lot of sense. I believe you also create a lot of content explaining how GraphQL works, correct?

Yeah, that's right. I've got OneWeekGraphQL. Com, which is a course a friend named Julian and I created. It's a one-week course where you build a GraphQL ecommerce store. You build the server and the front end with Next. Js, and we use the Next. Js API routes to serve the GraphQL API. Then we talk to a database using tools like Prisma and, I think, PlanetScale. There are tons of different things in there that we cover, all built around a typical application. The other resource is GraphQL. Wtf. I'm not going to say what that stands for, but you can figure it out.

That's a resource I started to create very specific GraphQL videos. If you're searching for how to do this with that, my aim is to have a video for those use cases in GraphQL projects, using GraphQL SDKs, tools, things like that, and cover smaller parts of it instead of only making longer content.

Perfect, and I'll make sure to have links to both of those resources in the description of the video itself. Jamie, it's been fantastic talking to you about this, learning from you, and having you share your knowledge about GraphQL while answering my mundane questions on what it is, why it's used, and maybe why we shouldn't use it. Thank you for taking the time to chat with me and educate everybody on what GraphQL does.

Yeah, thank you. Thanks very much for having me, and thanks for the great questions.