GraphQL in the Age of AI Agents - Insights from Apollo's CEO Matt DeBergalis

Speaker A: Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with some of the world's smartest engineers. Hey, I'm um, Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, want to know how to use GraphQL for faster testing, fewer bugs and AI ready APIs? In this episode of the Test Skill DevOps Toolchain, we sit down with Matt Dibergalis, 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. Hey, before we get into this episode, I want to quickly talk about the silent killer of 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 talk to on this podcast, frustrated users don't last long. But since slow performance is as sudden, it's hard for standard error monitoring tools to catch. And that's why I really dig SmartBear's Insight Hub. It's an all in one observability solution that offers front end performance monitoring and 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. Hey Matt, welcome to the Guild.

Speaker B: Thank you. Thanks for having me.

Speaker A: Great m to have you. I guess before we get into like, maybe a little background how you got into Apollo being the CEO, uh, what led you there?

Speaker B: 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 you know, we got started with Apollo by way of a, uh, 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 were engaging. There's a lot that goes into that. But the uh, kind of the soul of it was a uh, 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, 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, of larger companies that have existing APIs reworked so that you don't need to use it. With Meteor's 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, we had a lot of our users telling us, hey, you know, 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 have our application, so how can we bring this idea to the world as it is? And you know, you just, you follow what the users tell you and turn the crank on that and you end up with Apollo.

Speaker A: Cool, cool. So I guess just set uh, the field and people knew. What is GraphQL? I mean I've heard of Soap Services and Rest. Is this like a, uh, beyond rest? Is it on top of rest? Is uh, it some completely different? Yeah.

Speaker B: GraphQL is a language that lets you query your APIs. So we're used to calling APIs the old fashioned way. We're used to an API and it might be rest or it might be something like SOAP or something new like grpc, but it doesn't matter. Uh, it's an endpoint. And you know, 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 5 or I want all the GitHub repository data for this repository. And whoever wrote that API decides what you're going to get back and what form it comes in. And so 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 to write code that calls those APIs in a particular sequence. Maybe you want part of what came back from the first One maybe you want to feed that in as an input to the second one and maybe then you want to 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 want to 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, right? You describe declaratively what you want. And Apollo is an implementation of GraphQL. It's an implementation that's meant for the, you know, 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 deal 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, right? 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 writing a bunch of code, imperative code that does that. We're bringing that idea to the API layer.

Speaker A: So what advantages does someone get from that approach then?

Speaker B: Imagine a retail website. You go to a product page on a, 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 I, sometimes I will half heartedly go through the checkout flow. All I want to know is, is the thing going to come by Friday? And, and uh, so it turns out it's, 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 got a, you've got to call your inventory system to figure out what warehouse this thing's going to ship out of. You've got to call a bunch of third party shipping APIs to figure out what are the cutoff times for a shipment and the cost and when it's going to arrive. And there's probably some kind of a customer loyalty service that you have to call because maybe you want to 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. So 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 have a message bus underneath the hood. Or it's. It's these things that seem simple on the surface that turn into two, three, four, five month 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, you know, 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 a polygon graphQL gets you out of that conundrum.

Speaker A: 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, 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.

Speaker B: 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, right? It's a piece of software it's going to call your APIs. That's what MCP is all about. It's a 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. So 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. So what we're doing is adapting the APIs that tell you what's in your warehouse, tell you how long it's going to take to ship a product, tell you we're adapting all those to a world of agentic software. The combination's magical. And I think the future's all about not just a, uh, 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. Whereas 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 going to 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 going to need to do it in a way that fits the architecture of an agent. Turns out, GraphQL's fantastic for this.

Speaker A: Very cool. Another question that may not address at all. I'm just taking 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 know you're making a change to this service that has a dependency on this other service you may not be aware of.

Speaker B: Yep, 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. Right? You don't really understand the meaning of what's happening. All you've got with a, uh, 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, while 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, right? 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 it's. 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 going to, you know, 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.

Speaker A: Pretty cool. Also, I know a lot of teams struggle with um, like performance almost like over fetching data almost. Does GraphQL help anything like with performance wise? Yeah.

Speaker B: M. 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, it means your users go use some other app. So there's performance is at the heart of what GraphQL was 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. Right. And I, uh, 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. So 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 going to go pick the one that works best, that performs best for them. I think uh, 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, if you're racing to build an agentic experience for users.

Speaker A: So 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 to start adopting GraphQL?

Speaker B: Yeah, there's a uh, misconception I think sometimes, you know, 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, right? And especially today, with budgets tight, with enormous, uh, pressure to ship, I don't think too many teams are excited about reworking from first principles their whole API layer. So 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. So you're a little bit like something like Open API. You're defining in a more structured and precise way what each of the parts of the API response is and how it relates to other parts of the 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 have an API that returns a user object and a set of products in that user's shopping cart. And the real task when you bring in Apollo, and it's really 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, uh, 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 going to 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 instead of code, and it's night and day.

Speaker A: All right, So 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 um, 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?

Speaker B: 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. Right. It's very different from testing a bunch of code that somebody wrote. The edge cases and the uh, the SQL query engine, the GraphQL query engine in Apollo. These are pieces of infrastructure that are battle tested and they're reusable. So your testing surface area gets a lot tighter when you're using a declarative architecture. And there's all kinds of advantages. Right. You know, I mentioned typing before. So we can automatically create mock data for a uh, GraphQL query. That simplifies a lot of the testing burden. You can do more in the uh, you mentioned security, for example. A lot of security in GraphQL is done declaratively. You just write a policy rule that says, you know, this field is only accessible to users with this JWT claim. And again, just testing that is so much easier than testing every possible way that someone's handwritten code, uh, base may fail from a security point of view or performance or any of the other characteristics that you care about.

Speaker A: Can these artifacts be used like in an audit? I used to work for healthcare, FDA could come in or insurance, almost like, hey, uh, because it's readable almost, or you actually have proof of what was done or what's happening.

Speaker B: I think that's very much the future we do have. A lot of the healthcare 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. So in banking there are strict regulations in every country. They're different. So just think about the uh, 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. So 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 a choice as a consumer who you bank with. And you know you're going to pick the bank more and more. That's Got the best digital front door, right? You're going to pick a bank maybe that allows you to manage your checking account and your investments. Maybe you've got some crypto, maybe you want to, you know, there's, 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. So 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?

Speaker A: Right?

Speaker B: 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. And a ton of people have found GraphQL is the right solution because it gets you both. It's a principled architecture, so 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 can 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, right? So I think it's fair to predict that, uh, your banking experience not long from now is probably going to look very different. It's going to be agentic, it's going to be a lot more personalized. Here's another problem banks run into. So 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 want to see how much money they have. They don't want that number to change very much. You know, 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 they want to day trade. They want to be able to set, you know, different budgets for different things. They might be saving for. They want a much more dynamic and data rich integrated experience. So there's this challenge which is how do you make an app that does both of those things? Like how do you meet such different types of customers in one place? And that's where I think a Gentix software is going to be such a 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, uh, at the end of the day that's what I want, right? I want something that's built for me and my needs. And 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, when we've got something that's agentic, uh, I think it's going to 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 something principled, something that is secure and auditable, something that meets the legal requirements across all the different places that I want to 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.

Speaker A: It almost sounds like you're future proofing yourself as well. For sure.

Speaker B: The job of a, uh, 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 screw 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 and a hard place that I'm in. And this is what people, I think, find work really well for that.

Speaker A: Absolutely. So if someone wants to implement it, uh, are there any key lessons you've seen how they can implement it? Implement GraphQL the best way, uh, Are there any aha moments or things you're like, don't do that when you're getting started.

Speaker B: 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, no, no. Start with the user experience, start with what a customer is actually trying to do. Start with the piece of software you want to put in front of them and work backwards from that. And so a lot falls out from that. You know, sometimes people see GraphQL and they see a, uh, 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 right 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, uh, 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 want to bring into the user experience, or let's look at another experience that we want to build. And so we've really tried to steer toward a, uh, 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, uh, good result as you scale. That's the magic that we found works best.

Speaker A: Nice. So 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?

Speaker B: 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 want 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. Right. 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 uh, thoughtful platform investment can pay dividends.

Speaker A: You just mentioned something once again. Don't know if it's off the wall. I uh, 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 the unified platform. Uh, I used to find, you know, people would write their own code even though it already existed because they didn't want to break another team's code. Uh, so maybe they create an API and have multiple duplications. Does this help reduce duplication as well then?

Speaker B: Yeah, exactly. And like think about how microservices played out. Uh, I mean I talk to lots of people that I think a lot of companies have more microservices than developers at this point.

Speaker A: Right.

Speaker B: Because of that exact dynamic. Right. We the clouds, another platform make these containers or these virtual machines 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. So I think that is the right architecture, but you gotta kind of keep pulling on the thread and it gives rise to kubernetes. You gotta have a scalable way to manage and deploy and install all that stuff. You're gonna 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 you know, 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 that 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.

Speaker A: 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?

Speaker B: Yeah, there's lots of ways to do this. The fastest way is to use Apollo graphos. Everything's in the box there. And you know, 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 have to change, uh, 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.

Speaker A: Absolutely. Okay, Matt, before we go, is there one piece of actual 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?

Speaker B: 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, is, I mean there's, there's a billion downloads of this stuff and it, 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 you know, some of that's baked into the software, some of that's explained in the uh, documentation and the, you know, we 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 want to be.

Speaker A: All right, before we wrap it up, remember, frustrated users quit apps don't rely on bad App Store reviews. You use SmartBear's insight hub, um, 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. And for links of everything of value we 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, um, Joe. Thanks. My mission is to help you succeed creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. 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, uh, Test Guild, where you become part of our elite circle driving innovation in 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 test guild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve O the Tescill 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 uh land, guiding testers, showing us secrets to behold.