GraphQL in the Age of AI Agents – Insights from Apollo’s CEO Matt DeBergalis

[00:00:00] Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain Podcast and my goal is to help you create DevOps toolchain awesomeness.

[00:00:19] Joe Colantonio Hey, want to know how to use GraphQL for faster testing, fewer bugs in AI ready APIs? In this episode of The Test Guild DevOps Tool Chain, we sit down when Matt DeBergalis CEO of Apollo GraphQL to explore how GraphQL is transforming the way teams build, ship, and scale applications. Matt shares his journey from open source pioneer to leading one of the most widely adopted GraphQL platforms in the world and why GraphQL is more relevant than ever in the age of AI, microservices, and agent-based applications. You really don't want to miss this episode. Check it out.

[00:00:52] Hey, before we get into this episode, I want to quickly talk about the silent killer of most DevOps efforts. That is poor user experience. If your app is slow, it's worse than your typical bug. It's frustrating. And in my experience, and many others I talked to on this podcast, frustrated users don't last long, but since slow performance is a sudden, it's hard for standard error monitoring tools to catch. That's why I really dig SmartBear is Insight Hub. It's an all in one observability solution that offers front end performance monitoring and distributed tracing. Your developers can easily detect, fix, and prevent performance bottlenecks before it affects your users. Sounds cool, right? Don't rely anymore on frustrated user feedback, but, I always say try it for yourself. Go to smartbear.com or use our special link down below and try it for free. No credit card required.

[00:01:49] Joe Colantonio Hey Matt, welcome to The Guild.

[00:01:53] Matt DeBergalis Thank you, thanks for having me.

[00:01:54] Joe Colantonio Great to have you. I guess before we get into like maybe a little background, how you got into Apollo being the CEO. What led you there?

[00:02:02] Matt DeBergalis I mean, it goes way back. I was a kid who got super excited about open source and building tools, got to hang out with the Free Software Foundation people back in the 90s and learned at their hand how this stuff works. And we got started with Apollo by way of a JavaScript framework called Meteor that we built. And Meteor was in the early days of JavaScript and we wanted to make it really easy for people to build great apps, apps that ran in your browser, that were real-time, that that were engaging. There's a lot that goes into that, but the kind of the soul of it was a data synchronization layer that let you write queries instead of a bunch of code to move data between the cloud and the application. And that's what made Meteor so easy and fun to use is you didn't have to do the nitty-gritty work. Every time you wanted to talk to a new table in your database and draw a new screen, you just basically said what you want. And that's what Apollo is. Apollo is just the heart of Meteor's data layer, reworked for the needs of larger companies that have existing APIs, reworked so that you don't need to use it with Meteor built in templating system or package system or the other parts of the stack. It was made as a standalone product. And that all just came about because we had a lot of our users telling us, hey, we love this idea of a declarative way to build applications and to talk to our APIs, to query our APIs. But we already have those APIs, and we already our application. How can we bring this idea to the world as it is? And you follow what the users tell you and turn the crank on that, and you end up with Apollo.

[00:03:57] Joe Colantonio I guess, just set the field and people knew what is GraphQL? I mean, I've heard of SOAP services and REST. Is this like a beyond rest? Is it on top of rest? Is it some completely different?

[00:04:11] Matt DeBergalis Yeah, GraphQL is a language that lets you query your APIs. We're used to calling APIs the old fashioned way. We're used an API and it might be REST or it might something like SOAP or something new like gRPC, but it doesn't matter. It's an endpoint. And the rules of the road are the endpoint gives you back what it wants to give you back. So you call a REST API and say, I want user five or I want all the GitHub repository data for this repository. And whoever wrote that API decides what you're gonna get back and what form it comes in. And when you're building a real app, you don't just talk to one or two of these APIs. You talk to dozens and dozens of them. And so much of the work that you have to do is you have write code that calls those APIs in a particular sequence. Maybe you want part of what came back from the first one. Maybe you wanna feed that in as an input to the second one. And maybe then you wanna filter all that down and change the shape of it. Eventually, you get to what you actually wanted, which is just the data that you wanna put on the screen for the user. The idea of GraphQL is instead of writing code to do that, you write a query. It's a lot like a database. You describe declaratively what you want. And Apollo is an implementation of GraphQL. It's an implementation that's meant for the large scale companies that have thousands of APIs, companies that are building web and mobile and voice and AI apps that all have to feel as one and have a coherent user experience across all of them. And it brings that idea of querying all this stuff instead of writing code after code, after code after code to that environment that we're in. It's the same story as other parts of the stack. Kubernetes is a declarative way to package software and deploy software instead of writing code. React is a declarative way of explaining what you want the screen to look like instead of a writing a bunch of code, imperative code that does that. We're bringing that idea to the API layer.

[00:06:23] Joe Colantonio What advantages does someone get from that approach then?

[00:06:26] Matt DeBergalis Imagine a retail website, you go to a product page on a website. You want to know when that thing's going to show up on your door. That's basic table stakes, what a user wants. And I don't know if you've gone through this, but sometimes I will half-heartedly go through the checkout flow. All I want to is the thing going to come by Friday. And so it turns out it's really important if you're selling something online to be able to say on the product page, arrives by Friday. If you think about what's behind the scenes to make that happen, there's a whole bunch of API calls. You've gotta call your inventory system to figure out what warehouse this thing's gonna ship out of. You've got to call a bunch of third-party shipping APIs to figure what are the cutoff times for a shipment and the cost and when it's gonna arrive. And there's probably some kind of a customer loyalty service that you have to call because maybe you wanna make a decision to give people a really quick shipping time, maybe you want to make a different decision and have better margins. You're a retailer, margins matter. Something really simple in table stakes like that, if you really look inside what an engineering team has to do to ship, is very expensive. Those APIs don't all return as fast as you want. So maybe you have to build like a caching layer or maybe you a message bus underneath the hood, or it's these things that seem simple on the surface that turn into two, three, four, five months projects. And the advantage of Apollo is you cut through all that stuff. You just write the query. You just describe what you want. And under the hood is a query planner and a whole pile of infrastructure, just like in a database, that figures out how to call those APIs, what order to call them in, how to feed the output of your warehouse system into the input of your shipping system and then filter all that back down to get the result you want on the screen. So people can ship great software and they can ship it really quickly. And they can do it in a way that you can maintain going forward because the worst thing today is to race to put something in the market that only consigns you to more and more technical debt next year when you want to iterate on that or when there's a new product you have to build on top of that and a declarative architecture like Apollo GraphQL gets you out of that conundrum.

[00:08:40] Joe Colantonio For some reason, it popped in my head. I'm thinking of AI agents. Would this almost make it AI agent ready if someone used GraphQL because it doesn't have to know, like it just knows I make this query. I don't need to know like all the different calls that need to be made. I don't know if that makes any sense.

[00:08:56] Matt DeBergalis No, that is the question. And it's exactly right. If you think about the new software everybody's writing, it's an agent. So it's sort of like a web app or a mobile app. It's a piece of software. It's gonna call your APIs. That's what MCP is all about. It's way to talk to outside systems from your AI. But there's things that are really different about agents. If you feed too much extraneous information to an LLM, it wanders all over the place and hallucinates. We've learned that when you're building an Agentic app, it's really important to constrain what comes back to the agent. And the APIs that you've got weren't built for that. What we're doing is adapting the APIs that tell you what's in your warehouse, tell you how long it's gonna take to ship a product. We're adapting all those to a world of agentic software. The combination is magical. And I think the future is all about not just a chat experience on its own, but think about an agent where you've got a dynamic user interface that's adapting to what the conversation the agent is. Or the other way around, where as you click through your user interface, there's an agent that's maybe prompting you as a user. We've got a lot of our customers that are exploring some really cool stuff in that direction. And what we keep finding is, you're gonna build a lot of these. You're going to need a quick way to adapt the APIs and systems that you've got to this agentic world. And you're gonna need to do it in a way that fits the architecture of an agent. Turns out GraphQL fantastic for this.

[00:10:35] Joe Colantonio Very cool. Another question that may not address at all. I'm just thinking shift left. If you're in microservices and you're developing, you may not even know that an API has a dependency on another API, maybe five APIs down the road. Can this bubble up? Hey, you're making a change to this service that has a dependency on this other service. You may not be aware of.

[00:10:56] Matt DeBergalis Yup, it does. Put yourself in the shoes of a microservice owner. You have no idea, really, how your service is used. You probably know what software is calling your endpoint. You do not know what other endpoints the software is calling in relation to yours. You don't know what parts of the API response the software actually wanted and what parts it just threw on the floor. You don't really understand the meaning of what's happening. All you've got with a traditional API like REST is this request response information. So-and-so made a call, it took this many milliseconds, and I'm done. What they did with it is not my concern. And what this declarative approach does, what it means when you have GraphQL, is now you actually have a much clearer end-to-end understanding of the whole picture. And again, think about agents. At least, in the world of mobile apps, somebody wrote that code. And so you could look at the code and figure out what it's doing. It's slow and it's expensive to do that for an engineering team. For an LLM, you have no idea. There's this mysterious thing between what the user's talking to the agent about and what the agent decided it wanted to do. And this is what I meant earlier about adapting APIs to agents. You have to enforce policy rules. You've got to have some level of control over an agent that's not deterministic and it's gonna, that's what makes them so valuable, but it's also really important to constrain and govern and control the way that those agents go talk to your underlying data.

[00:12:34] Joe Colantonio Very cool. Also, I know a lot of teams struggle with like performance almost like over fetching data almost. Does GraphQL help anything like with performance wise?

[00:12:46] Matt DeBergalis Yeah, the original calling card for GraphQL was limit the amount of data that comes back from your APIs because that data is expensive. And if you're on an old Android device, for example, that means lower battery life, means your app is slow, means your users go use some other app. So there's performances at the heart of what GraphQL is always meant for. And the world of agents makes that so interesting because Performance isn't just about how fast it is. It's also how good it is. And I was talking about this before. If you put too much context into the agents, you're going to get back worse results than if you constrain the context you give to the agent. We're going beyond performance just measured in terms of how many milliseconds before your page renders. And we're starting to look at it through this much broader lens of users have choice in the software they use. And they're gonna go pick the one that works best, that performs best for them. I think a layer like this that gives you visibility into it and gives you fundamental architectural benefits, really adds a lot to the picture if you're racing to build an agentic experience for users.

[00:14:02] Joe Colantonio We're only 13 minutes in, and I think this is a no brainer already. But like, what does a team need to have in place in order to implement it? Is there any overhead or do they need to be designed a certain way or anything like that in order start adopting GraphQL?

[00:14:16] Matt DeBergalis Yeah, there's a misconception. I think sometimes, if people see GraphQL as a different kind of API from REST, then that can take you down a path of thinking to take advantage of all the stuff we've talked about. I've got to rewrite all my APIs as GraphQL APIs. That's expensive, that's hard. And especially today with budgets tight, with enormous pressure to ship. I don't think too many teams are excited about reworking from first principles their whole API layer. That's why we talk about GraphQL, not as a different kind of API, but as a query language for the APIs you already have. You don't need to change those APIs at all. The way Apollo works is you write a description of what your APIs do. There's a language for that called GraphQL. And that description basically just is a way of providing the semantics. So in GraphQL, we've got comments, English comments that explain in English what each part of the API is for. It turns out that's very valuable for an LLM. We've got strong typing. You're a little bit like something like OpenAPI. You're defining in a more structured and precise way what each of the parts of the response is and how it relates to other parts of API. And the most important thing you're doing is you're basically defining the objects, the semantic objects that come back from your API. If you look at almost any API, what it's really doing is returning an object or a set of objects, right? You might have an API that returns a user object. You might an API that returns user object and a set of products in that user shopping cart. And the real task when you bring in Apollo, and it's real easy to do, is take the technical API that you've got, a list of things that come back in this JSON format, and translate that into a description, an object model of what's inside the API. And once you've done that, that lets Apollo know how to connect APIs together. I can write a query that turns into, first I'm gonna call the user endpoint to get some user information, and then I'm going to go call the product endpoint to get a bunch of information about the products in the user shopping cart. And all that happens behind the scenes for you because you've defined this graph, this relationship between the different objects that are there, and that's all there is. After that, you're just writing queries and set a code, and it's night and day.

[00:16:49] Joe Colantonio All right. I actually have a software testing background, not a developer, but this sounds like it would help me be able to test it almost, or even have conversations with the developer better because I'd have a graph to say, looks like it's doing this or that, or maybe find security issues. I don't know. I'm just making that up right now, but does that help with those areas as well?

[00:17:09] Matt DeBergalis Yeah, it does. I mean, declarative architectures are really great from a testing point of view. If you think about testing a SQL query, for example, it's very different from testing a bunch of code that somebody wrote. The edge cases and the SQL query engine, the GraphQL query engine in Apollo, these are pieces of infrastructure that are battle tested and they're reusable. Your testing surface area gets a lot tighter when you're using a declarative architecture. And there's all kinds of advantages. I mentioned typing before, so we can automatically create mock data for a GraphQL query that simplifies a lot of the testing burden. You mentioned security, for example, a lot of security in GraphQL is done declaratively. You just write a policy rule that says, this field is only accessible to users with this jot claim. And again, just testing that is so much easier than testing every possible way that someone's handwritten code base may fail from a security point of view or performance or any of the other characteristics that you care about.

[00:18:22] Joe Colantonio Can these artifacts be used like in an audit? I used to work for health care, FDA could come in or insurance almost like, hey, because it's readable almost or you actually have proof of what it was done or what's happening?

[00:18:34] Matt DeBergalis I think that's very much the future. We do have a lot of the health care industry has gravitated toward GraphQL. And I think you're hinting at why. I'll give you another example in banking. This will probably be pretty intuitive, like highly regulated industry. In banking, there are strict regulations. In every country, they're different. So just think about the layers and layers of all the things that have to be done a certain way. That's on the one hand. On the other hand, in the old days, your bank was the bank in your town. You didn't really have a choice. You go to First National Bank of wherever you live and that's your bank. Today, it's not like that. Today, you really have choice as a consumer who you bank with. And you're gonna pick the bank more and more that's got the best digital front door. You're gonna pick a bank maybe that allows you to manage your checking account and your investments. Maybe you've got some crypto. Maybe there's all kinds of different things that tie into your financial world. And if you look at any bank today and you open up their mobile app, what you'll see is this dynamic of banks sort of spreading their wings and trying to have more and more of a 360 degree touch point around your financials. You've got credit card offers and you've got partners. And it's gone a long way from like, here's your checking account balance and your recent transactions that you conducted. How do you solve that? If you're a bank, you've got to move quickly or you're going to lose your customer to somebody that's got new fresh software that just makes a lot more sense in 2025. And you've got to do it all in a way that's copacetic to all these rules. A ton of people have found GraphQL is the right solution because it gets you both. It's a principled architecture. The development can go a lot faster because there's just a lot less code to write. And the concerns around security, repeatability, auditability you mentioned is a really important one. The idea that in GraphQL you can implement policy in a much more structured way. You can also audit that policy and you have all kinds of change management and structured workflows around how all that works. That's a huge prize for any company that's facing this pressure to meet the customer where they are with a new kind of experience. And then again, here come agents. I think it's fair to predict that your banking experience not long from now is probably going to look very different. It's going to be Agentic. It's gonna be a lot more personalized. Here's another problem banks run into. Say you open up your banking app on your phone. Some of your customers are retired. They think about their bank as a safe place to put their money. They open the app and they wanna see how much money they have. They don't want that number to change very much. Kind of a classic, like, you're the custodian of my funds. There's a new generation of customers who open their banking app and want a day trade. They want to be able to set different budgets for different things they might be saving for. They want a much more dynamic and data-rich integrated experience. There's this challenge which is how do you make an app that does both of those things? Like how do we meet such different types of customers in one place? And that's where I think Agentic software is going to be such an exciting development because it allows us to start to hyper personalize these applications for each user in a different way. And I think in the future, when I open my bank app and you open the same app on your phone, based on how we've interacted with the bank and who we are, that app might start to feel very different for the two of us. That's cool, because at the end of the day, that's what I want. I want something that's built for me and my needs. We haven't been able to do that in the past because these software projects are hard to build and you can only have a couple of them and you throw a lot of product managers and designers and all the people involved in the process at this. But in the future when we've got something that's agentic, I think it's gonna be very, very different. And again, the question is, how do I do that? But we're at the end of the day under the covers, I've got some thing principled. Something that is secure and auditable, something that meets the legal requirements across all the different places that I wanna do business. I think it's a bright future for, not just GraphQL and Apollo, but for all the declarative architectures across the stack. That's how you solve for that.

[00:23:25] Joe Colantonio It almost sounds like you're future-proofing yourself as well, fore sure.

[00:23:30] Matt DeBergalis The job of a VP of engineering is really tricky, because on the one hand, you are under enormous pressure to ship, right now. And on the other hand, if you screw that up and you consign your company to the wrong architecture tomorrow, or if you screwed that up and you ship something that has a big security breach, you get fired. That's a tough job. And I think a lot of the conversation around these modern architectures around Cloud Native, around GraphQL, and Apollo. It's all about like, how do I navigate that rock in a hard place that I'm in? And this is what people I think find work really well for that.

[00:24:11] Joe Colantonio Absolutely. If someone wants to implement it, are there any key lessons you've seen how they can implement GraphQL the best way without any other any aha moments or things like don't do that when you get started?

[00:24:23] Matt DeBergalis The biggest thing we've learned is it's really important to start with what the user wants. In the old days, I think a lot of technology was oriented more around what the system can do. And then the user kind of had to live with whatever that meant. The whole idea of GraphQL is, no, no. Start with the user experience. Start with what a customer is actually trying to do. Start with a piece of software you want to put in front of them and work backwards from that. And so a lot falls out from that Sometimes people see GraphQL and they see a principled object model, and they think, great, I can define a graph that combines every API that I've got and I can kind of write the wrongs of the last 20 years. I can fix all the flaws in my underlying APIs. We found that instinct isn't the right one. What's much better is to just take a step-by-step incremental approach where the goal is to ship some piece of software that works well for a user. Just do the small, narrow GraphQL that lets you do that. Then you can expand from there. Let's look at another API that we wanna bring into the user experience, or let's look in another experience that we want to build. And so we've really tried to steer toward a bottom up, an approach that allows the teams that own software, own roadmap to be able to move very quickly and serve their users. And then just try to keep architectural integrity underneath that so that path gets you a good result as you scale. That's the magic that we found works best.

[00:26:01] Joe Colantonio Nice. Another thing I know a lot of developers struggle with is DevOps and platform engineering and observability, measurability, that whole thing. I know Apollo has like Apollo Studio. Is there any other features that Apollo has that helps with this more modern type of development?

[00:26:16] Matt DeBergalis Yeah, what we find normally happens with GraphQL is that GraphQL becomes a platform and a platform engineering group at some point is going to want to take advantage of that to empower developers across their whole org. And also they're going to bring some consistency and some best practices and standards to that. So we always look at this through both lenses. There's the end users that want to ship software. I talked about that earlier. And then there's the platform owners that want to make sure they're providing it the right way and that they're doing it at scale in a maintainable form. Again, I think this is where declarative architectures and the whole cloud native stack shine because they give you both. They give you a way to make these products self-service so that you, as a platform owner, can offer it to anybody in your org and there's no gatekeeping, right? I don't have to go to the platform team if I want to write a GraphQL query. I get to write whatever query I want. And the query is based on what I'm trying to ship and how I want it to behave. The platform's job is to make sure the query I write doesn't mess up somebody else's query. Like there's an isolation property to every great platform. And so there are all kinds of things. You mentioned observability, scalability, deployment models. All of these are areas where a thoughtful platform investment can pay dividends.

[00:27:44] Joe Colantonio Or you just mentioned something, once again, don't know if it's off the wall. I forgot what the point was, but you mentioned something like they don't want to break anything, I think the developers, and so they have this unified platform. I used to find people would write their own code, even though it already existed, because they didn't want to break another team's code. So maybe they create an API and they have multiple duplications. Does this help reduce duplication as well then?

[00:28:07] Matt DeBergalis Yeah, exactly. And like think about how microservices played out. I mean, I talked to lots of people that I think a lot of companies have more microservices than developers at this point, right? Because of that exact dynamic, the clouds, another platform, make these containers or these virtual machine self-service. That means when you're building a piece of software, it's easy just to write your own net new service instead of having to worm your way into somebody else's code and add your requirements and teasing those apart lets everybody move a lot faster. But when you do that, now your prize is you're the proud owner of thousands and thousands of APIs, thousands and thousands of microservices. I think that is the right architecture, but you got to kind of keep pulling on the thread and it gives rise to Kubernetes. You got to have a scalable way to manage and deploy and install all that stuff. You're going to need a graph layer because you need to have a scalable way to tie those things all back together without writing a bunch of code that entangles them, and so on. And it's the age old conundrum. Do I extend what already exists or do I make something net new? And I think the platforms that have done the best are the ones that reward both choices by not painting you into corners. They give you a structured way to do what makes the most sense for your needs. There's never a single pat answer in my experience around this stuff.

[00:29:32] Joe Colantonio I know we're at 30 minutes, but I forgot to ask a question. So people get started with open source and then move into Apollo's paid solutions. Is that how it works?

[00:29:41] Matt DeBergalis Yeah, there's lots of ways to do this. The fastest way is to use Apollo Graph OS. Everything's in the box there. And our goal is to get you up and running with working GraphQL in under an hour on top of the APIs you have. So you don't have to rewrite your APIs as GraphQL services. You don't to change anything about your stack. Like any product in the infrastructure space, it's built out from components. And you can use those components individually. If that makes more sense for your needs. All of that's on our website and on GitHub. And as I mentioned before, that stuff sits behind many of the products and services that people use every day.

[00:30:24] Joe Colantonio Absolutely. Okay, Matt, before we go, is there one piece of actionable advice you can give to someone to help them with their GraphQL DevOps efforts? And what's the best way to find, contact you and learn more about Apollo?

[00:30:35] Matt DeBergalis I guess it's the same for both questions, go to Apollo.dev and we have worked with virtually everybody out there that's doing GraphQL at scale, Apollo is open source, there's a billion downloads of this stuff and it powers lots of the household names that you use on your phone or on the browser every day. There's a lot of lessons learned inside that and some of that's baked into the for some of that's explained in the documentation and have a well-architected graph framework that's based on Amazon's well-architected framework approach that I think is really helpful. There's just a ton of hard-won lessons that can point you in the right direction and help you move really quickly to where you wanna be.

[00:31:25] All right, before we wrap it up, remember, frustrated users quit apps. Don't rely on bad app store reviews. Use SmartBear's Insight Hub to catch, fix, and prevent performance bottlenecks and crashes from affecting your users. Go to SmartBear.com or use the link down below, and try for free for 14 days, no credit card required.

[00:31:47] And for links of everything in value we've covered in this DevOps ToolChain show, head on over to testguild.com/p200. So that's it for this episode of the DevOps ToolChain Show. I'm Joe, my mission is to help you succeed in creating end-to-end full-stack DevOps ToolChain awesomeness. As always, test everything and keep the good. Cheers.

[00:32:09] Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing, and DevOps. If you haven't yet, join our vibrant community at TestGuild.com where you become part of our elite circle driving innovation, software testing, and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit TestGuild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

[00:32:52] Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.