Apollo GraphQL’s Matt DeBergalis on Rising API Development

This is Textron tv. Hey guys, thanks. Re we're here with Matt de Burgles, who is CTO for Apollo Draft ql.

And we are talking about the rate at which, um, this new API format is being adopted. 'cause there's a lot of folks who are still using rest and we'll probably have a mix of these things going forward, but use cases are changing always. Hey Matt, welcome to the show.

Great to be here. So what exactly is going on with GraphQL? 'cause we've been talking about it for a while and clearly it provides a more, uh, shall we say, richer approach to getting access to data than I can see with rest, but I still see tons of rest out there.

So, um, when do I use what these days and how often are people using GraphQL? A big problem it solves is how you combine those rest APIs to make a great customer experience. And if you think about the last 10, 15 years of cloud native and microservices, containerization, companies have built more and more APIs, rest APIs that represent all of these capabilities.

They have these business capabilities. And the challenge is, if I'm a retailer, for example, how do I bring all that together on the screen for the customer? How do I make a table stakes experience that has dynamic pricing and user generated content and maybe some machine learning for product reviews?

You need all that together. And GraphQL has emerged as the technology of choice now in the enterprise for, as you said, a flexible and richer way to combine all of that fundamental capability, um, in flexible ways for the customer. And we've seen some enormous momentum, particularly over the last year in not just retail, but banking, automotive, uh, media, sports and entertainment, really across a wide range of companies wide.

This common need to be able to meet the customer where they are with a really delightful, uh, set of experiences. Is it getting easier to work with GraphQL? I think initially a lot of folks felt that the borrowers on the high side compared to rest API, where are we now in terms of accessibility?

Yeah, We've made a lot of progress. GraphQL fundamentally is a platform approach. What that means is that it empowers individual teams inside of a company to be able to, on their own, um, ask for the data they need to make that user experience, uh, and owners of APIs to be able to publish what they can provide into that common graph.

So when people say GraphQL today, they're referring to a very particular kind of architecture, what we call GraphQL Federation, to roll that out. Like any platform, there's an adoption curve that that's the same critique that got levied with hyper clouds, with Kubernetes, with so many of the other things. But I think the trend is absolutely clear that these platform approaches that allow companies to leverage these investments and to be able to do more with the engineering capabilities and the teams they have, are absolutely the right ones.

So our focus over the last year has been not just making GraphQL more accessible, but but making this platform approach to it be something that's understood and, and has a, a paged path for a, a company. Anytime we go into a a, an enterprise, they're gonna have thousands of existing rest APIs. GraphQL is not a replacement for those at all.

It's a layer that floats above them. And so the, uh, the product investments, the educational work we've done to make that approachable for teams and help them understand how best to take advantage of it and get some really quick wins, um, has been really important for us. And, and I think we've made a lot of progress there as a industry.

We hear a lot about platform engineering teams as a methodology for scaling DevOps. Are they at the forefront of this approach to GraphQL? Because it seems like they are trying to take thousands of rest APIs in hand and kind of make them more accessible because, um, to your point, every user experience now seems to involve multiple APIs.

Exactly. W without GraphQL, when you want to build a new experience, you have to go order up a new API from some other team. That's, that's how applications get built today, and that's the opposite of the platform approach.

The, the, the way platform engineering works is you replace handcrafted one-off code like that with a modular declarative architecture. In the old days, you had to request a new server and now you can call an API and get a virtual machine. And that's the, the advantage of a platform approach.

That's why, uh, containerization spread so quickly. It's, it's why so much of the cloud native stack has been, uh, improved over the last five years. And I think APIs are the next forefront.

That's the right way to do engineering. And the platform minded teams are now turning their attention to the API layer and asking the same questions. How do we bring a declarative modular approach to this layer of the stack?

And how do we do it in a way that empowers and and, and improves, uh, the work of all the teams that surround us? It's really a service mindset, uh, when you look inside platform teams. And I think that's the, the template for how we can make great strides in our ability to, you know, build great customer experiences on top of all these other investments.

I will tell you that this topic continues to, uh, generate a lot of emotional response, shall we say. And I guess did we fall into some sort of trap about GraphQL versus REST APIs when in reality it's one of these kind of peanut butter and jelly better together things Better together is exactly the way we think about it. And, and I think this is common with any new technology, is it, it takes it, it takes some time for people to understand the context.

Um, it's, it's true that in the early days of GraphQL some of the devotees of the technology, um, to IT as a replacement for REST APIs and from the point of view of an application developer GraphQL is day and night compared to the rest APIs they're used to using. It's so much more capable and flexible. You write a query instead of writing a bunch of data fetching code and state management code.

So that's an accurate technical description of GraphQL, but it turns it out. The value of this approach is so high in larger, more established companies, those are the companies that have accumulated thousands of APIs, and those APIs have been built in different eras of technology. So you don't have any commonality about the language.

Many times we have customers that have acquired, um, some of their API Surface area and m and a turns out to be a important use case for rolling out GraphQL because typically the whole point of the acquisition was some sort of synergy between two products. And the task is how do you bring 'em together? How do you combine them into a single user experience?

So we've learned over the last year or two that it's very important to bring GraphQL in a particular way to the enterprise, which as you said is a better together approach that leverages the rest APIs that exist and frankly makes them more valuable. It's if, if you're an API owner today, it's valuable to make that API more accessible to more use cases. It's valuable for that API to have technical capabilities like real time inqueries, that GraphQL allows you to offer your users without having to change the implementation yourself.

And that's the message that's starting to spread. That's the, when, when people talk about the rise of graphe in the enterprise, we're talking about this layer that fits above the rest APIs, um, and, and makes them more, more approachable and accessible. We're not talking about a replacement at all.

Mm-Hmm. Do you think that the rise of AI in some way will force this conversation? Because it seems like all these, uh, AI models are invoked via some sort of API and there's a lot of data generated by the models.

So I'm wondering if GraphQL kinda lends itself better to that use case than traditional rest APIs per se. It it absolutely does. AI is today's example of the kind of flexible experience that customers are going to expect.

It's, it's a different way to interact with the business and ultimately, uh, the job of a API team is so challenging because you're, you're under so much pressure to ship the experience of today. There's a roadmap that has to get out into the market, but you have to do it in a way that creates flexibility for use cases that are gonna come tomorrow. And with ai, I think everybody's now looking ahead a couple steps.

And you know, what's coming is agents, what's coming is a world where, um, on your behalf, some kind of an AI is gonna want to interact with different businesses that you have a relationship with. So you have to prepare for that level of flexibility. And this is exactly where Graph Shines.

It's about creating not a fixed set of endpoints that do very specific things designed for one application experience. It's about creating a flexible interface to the business that lets the customer explain what it is they want to do. That's just a fancy way to talk about a query, and it gives you a principled layer of the stack where you can implement policy because you're not gonna let any customer do whatever it is they want you, you need to have, and you're not gonna trust the LLMs.

I think that's clearly one of the lessons of how this technology works. You're gonna need a layer that allows you to understand the intent of the user, the intent of what the LLM is trying to do, and be able to add governance in the right place because it's a declarative technology. Because the, the way that GraphQL works is not by handwritten code, but by a, a query planner and a set of rules that it follows.

It's the exact right layer we think, where you can have the best of both worlds. You can give a flexible experience to the customer while having actually tremendous precision, uh, and, and control over what it is that customer's trying to do and how you wanna change those, uh, abilities over time. We're, we're very excited about that direction.

It's gonna be a big part of what we talk about over the coming few months. There's also a lot of talk these days about API security. Is the way we secure GraphQL different than we might secure other APIs we've known, or is it pretty much the same?

Well, GraphQL lets us take security a step further. It is another kind of API So you can start with all of the security techniques that we've always had for APIs, considerations like, um, access control or rate limiting. These are very common across GraphQL, rest thrift and GRPC.

And so there is a, a common angle to this, but we can go a step further with GraphQL because of that declarative approach. The challenge with securing APIs today is that there's no semantic understanding of what the API is doing. It's a piece of handwritten code and there are limits to what can be done by inspecting API traffic or running it through some kind of a security proxy layer.

With GraphQL, we have semantics In GraphQL, you're really defining business objects. We have, um, a way to talk about a customer or a product or, um, a price. These are actual nouns in the taxonomy of what you define in GraphQL.

And that opens up a lot of new and exciting opportunities for security. You know, for example, in GraphQL, and you can annotate the parts of your data model that are considered personal information. Uh, those are now subject to some set of additional rules.

For example, you may not allow certain requests for personal information. Um, it doesn't matter what other data's being requested, it can still give the application developer all the flexibility that let them go quickly. But now there's a set of common, uh, you know, policies that are enforced across all of that.

And I think there's a lot of opportunity to add, uh, a layer of security and a layer of, uh, governance, uh, to the way that, uh, businesses expose their data and, um, and, and, and how, and how people are allowed to interact with that. So ultimately, who's in charge of GraphQL APIs? 'cause clearly it takes somebody on the development team to create them, but it seems like the ongoing caring and feeding of those APIs may be shifting.

Yeah, this is the platform model. So what we, what we see and and what we recommend is there's, there's gonna be a team that really owns the layer of the stack. Uh, that's a horizontal responsibility.

And that's about, uh, the infrastructure that runs the graph execution. It's the, um, common policies like we talked about around security that can be applied across all of the organization. And then, um, their role is really to enable and empower the individual, API owners to bring that data into the graph and to enable and empower the application developers that are consuming from the graph.

When you do this the right way, the the graph becomes a marketplace in inside the company. It's a common destination for everyone who's producing something of value. Those are the API owners and everyone who's consuming something.

Those are the API, um, consumers, the application developers, uh, to, to come together in one place. And, and there's actually a lot of commonality, um, to the way that, you know, great marketplaces work when you do them well. It, it starts with understanding the needs of both of those constituents.

And again, this is the, that trend of platform engineering in a different mindset that, um, I, I think really creates a lot of opportunity, especially in, in this year where with interest rates and, and the focus on cash flow now, uh, the ability to help teams be more productive more quickly, and to avoid duplicated effort across teams, not just the effort of building the APIs, but if you think about the 20 year lifecycle commitment to an API and how expensive that is, when you can replace that with a query and, and keep those teams focused on building the kind of user experience that really drives the business forward, it is, it is just fundamentally, uh, transformational for a company. All right folks, you heard it here. There's a new era of APIs out there, but the thing that is, these, they don't have to throw out everything you have been doing.

It's more of a an and rather than an either or equation. Hey Matt, thanks for being on the show. Hey, appreciate it.

Enjoyed it. Cheers. All right.

And back to you guys in the studio.