Transcript: APIs as Graphs not Endpoints, building a company on open source foundations, why VPs of Engineering face impossible trade-offs | Apollo GraphQL CEO Matt DeBergalis

Host: I think one of the surprising things is that often open source on its own doesn't get a ton of adoption, especially when it's designed for the needs of a larger company.

And you mentioned data bricks and spark, so so here's an example, right? I think I think one way to look at data bricks. Ali will talk about it this way is that they built the company because people weren't adopting spark.

Why weren't they adopting spark? Because it was hard. It it's a complicated piece of machinery. If you think about the enterprise sale process, a lot of the enterprise sale process is really about helping the would be customer navigate the decision.

Like, yeah, they're going to write a check, right?

There's a, there's an exchange of money, but the much bigger cost to adopting any of these things and and and I'll talk about in a second, but it fits into this the same way is it's a, it's a complex multi stakeholder architectural decision.

So if you think about the time that goes into making that choice, and then if you think about the the number of hours or or the number of people that you're going to invest in that once you've made that choice, that's not a small decision for a lot of companies.

The VP of Engineering job at a company, I think is is maybe the hardest job today because on the one hand, you are under enormous pressure to ship quickly. This is, this is not the IT of 20 years ago.

If you ship slower than your competitor, that's probably like the end of your viability as a company. Like if you're a, a retailer and you can't keep up with the modern expectations of a, you know, consumer that wants to buy stuff online.

I think the the customers are going to walk. Hello everyone. Welcome to startup Project. My guest today is Matt. He's the co-founder and CEO of Apollo GraphQL.

He was previously the CTO of Apollo GraphQL and also co-founder at Meteor Development Group.

In this conversation going to talk about GraphQL, the evolution from open source to a product company, building and scaling APIs and the future of API development.

If this is the first time listening to startup Project, don't forget to subscribe to us wherever you listen to the podcast. You can also subscribe to us on Substack at startup project.substack.com. Matt, welcome to the show. Thanks for having me.

So I think a good place to start would be, uh, you know, you're now CEO of Apollo GraphQL. Um, can you give a look like a two minute history of, you know, your journey till now? Yeah, we um, we started the company. Uh, you mentioned Meteor.

Meteor was a JavaScript development framework. And, uh, this is the era of the first apps that were really built in the browser as as apps.

Um, and one of the things that you end up needing when you build software that way is a principled story for how you move data from the cloud into the application. Um, GraphQL and Apollo is really the heart of that story.

And what we found as we were building Meteor is that that piece of the stack, the piece that brokers the flow of data from your, your underlying databases and APIs and all the, all the systems that feed your software, the, the, the, the piece that brokers that up to the app, is where there's a ton of complexity.

And also a ton of the handwritten code that that accounts for a huge fraction of why it takes as long as it does to build good software. Um, and GraphQL is wonderful. It's a declarative language.

So you can build infrastructure around it and and we see this happening all over the stack, right? Kubernetes is an example. React is an example. So, Apollo is, is that for your APIs.

It's about, um, replacing all of the, the single purpose bespoke code that you might write with a, a piece of infrastructure and a principled programming model around it.

And, um, it the name GraphQL hints at the thing that makes it really wonderful, which is that in GraphQL we treat your systems and your data and your services, not as individual endpoints that you have to call imperatively, but rather as a connected graph of objects.

And that completely changes the development experience. It makes it possible to express really complex, uh, combinations of data in a very simple and deterministic way.

There's a query planner in there so you can do all kinds of, um, transformations and and other things that are necessary to build software, um, in a again, repeatable and understandable way.

And we've found that that really helps companies, especially larger companies with lots of APIs dramatically accelerate how fast they're able to build good stuff.

So, um, at what point, so GraphQL was initially open source, um, and you are working on Meteor. Like at what point do you said, okay, there's enough opportunity to be able to make this a, you know, new company? Couple of things were going on.

One is that the original version of Meteor was based on MongoDB. So, we got a lot of requests to support other databases and other data sources, um, to support REST APIs as well. The, the Meteor development experience was, was almost like black magic.

You would write a MongoDB query in your client code.

So it's database queries, but they're in your client code, and what Meteor was doing in the background was running that same query on the Mongo server in the cloud and synchronizing the query results across the wire.

So there's this whole pile of infrastructure that was efficiently allowing you to in real time, um, keep those in sync. And the consequence of that is that Meteor apps were, were real time.

You, you write a query and you connect that to some component on your screen and as the database changes, maybe because another user is, is doing something in a different browser tab, the screen automatically updates for you. And that's amazing.

That's, that's the sort of thing that's just out of reach for a developer, especially in those days. Um, but it had to be in MongoDB. So we needed a query language that would support more than just Mongo. We needed something more general than that.

And and we needed that just as Facebook announced, um, GraphQL. So that's part of the answer is, is we needed a query language and and this one looked good.

The other part of the answer is, and I think this is why GraphQL has flourished where a lot of other similar ideas haven't is GraphQL is, is in my view, the, the first API technology that really asks what, what are the needs of the the clients as opposed to the, the server, the consumer of data instead of the provider.

When we think about an API like a REST API or you can go back in time to, you know, ONCRPC or Soap or whatever, all of those APIs, they're all defined by the server. Yeah. And the consumer, you know, you get what you get.

Like, this is, this is the payload. This is what comes back. This is the format. This is the protocol you have to use.

Um, and it puts a huge burden on the application developer because it's rare that exactly what's coming back from the API is exactly what you need. You, you might need to filter it down or transform it or join it to a different API.

GraphQL has this incredibly good developer experience if you're the consumer of the API. You write a query. It's strongly typed. So there's great tooling support in your editor.

Now there's great tooling support in your agentic editor because it's semantic and self documenting. All these characteristics made it exciting for developers.

And I think a lot of the story of what technologies win is as much about the feeling that a developer gets when they try it. It's as much about how easy it is to use, how quickly you can get to something that's that's good.

As it is about any sort of inherent capability or property of the technology. So, that was the other thing we saw. GraphQL had that that unusual just delightful characteristic.

It came out of the the same team that did React at Facebook, so it had a lot of energy and excitement as web development was starting to move into that modern era that we're in now. And those two things together for us made it a really easy choice.

And I I think ultimately the right one for what we wanted to put in the center of our architecture.

I think one interesting thing I always see with Meta, is so many interesting developer technologies came out of Meta that were not sort of monetized by them because they always consider themselves as like they have a self definition that they're a social media company, they're a social networking company, so we're not do ancillary things that are smaller opportunities, versus you look other big tech companies like Amazon or Microsoft, they'll do anything that is tangential to their business or try it out to see if there's a big business possible there.

Um, so that's a little bit unique to Meta, I feel, because they always like self impose that, uh, you know, because why wasn't there a fourth cloud?

Because Meta is sort of like a great technology company, everyone who goes there, developer friends I talk to, um, you know, their ability to ship software is so good and the developer experience internally is so good.

So why hasn't Meta like done an Amazon and came up with another cloud? Is it like often a question? Um, and obviously there are better business decisions there, but that's something I always wonder. Why why didn't Meta come up with the cloud?

Because they have the money to do that. They're one of the few companies which can invest in a big opportunity like that. Um, but they never did. Um, but talk to me a little bit about here's one quick thing though. Um, to that point.

A lot of the energy around React, for example, really came out of recruiting. Like a a lot, a lot of companies do this, not just Meta. The open source was a tool for driving an engineering brand. And for especially in that era, right?

This was, this was when it, it became very, very difficult to hire. And there was a war for, uh, application development talent.

And so one of the reasons and I I think there's a lot, but one of the reasons to open source something like React, even if there's no direct business reason, I mean, it's it's hard to monetize React.

Like I I think Vercel is probably the best example of what that might look like and that's a pretty tenuous connection, right? But if it, if it allows you to recruit, you can, you can justify a lot of it, um, uh, a lot of it from there.

Yeah, I think that that's a very important point. I think even Microsoft changed his strategy to open source and like being one of the biggest open source contributors, I think it's probably one of that reason. It's a branding exercise.

Yeah, that that makes a lot of sense. So, you know, a lot of open source technologies, you know, like GraphQL or Vercel came out of, I think, React. Uh, and you can pretty much see like any open source database, you know, Android, to Mongo.

So we have these open source products that find some kind of developer love or a product market fit and then it transition like a group takes, uh, like even data bricks, right? I think they were the original creators of Apache Spark.

I think that key went and created data bricks. Um, so talk to me about the challenge of taking great open source product and converting into a, uh, a product that is worth paying and then making a business out of it.

Like what was that journey like for GraphQL? Well, um, there's a lot of ways to answer that. I think one of the surprising things is that often open source on its own doesn't get a ton of adoption.

Um, especially when it's designed for the needs of a larger company. I mean you mentioned data bricks and spark, so so here's an example, right?

I think I think one way to look at data bricks and and Ali will talk about it this way is that they built the company because people weren't adopting spark. Why weren't they adopting spark? Because it was hard.

It it's a complicated piece of machinery.

And if you think about the problem it solves, well, the person tasked with solving that problem, the company that needs that problem solved, all all these questions around how you're going to bring together a bunch of different data sets that you've got and do business analytics or or whatever else you might want to do now, like, you need a lot more than Spark.

And I I think usually the best vehicle for solving those kinds of problems is a business because it allows you to create a whole product, a solution, sometimes people will call it, right?

And if you think about the enterprise sale process, a lot of the enterprise sales process is really about helping the would be customer navigate the decision. Like, yeah, they're going to write a check, right?

There's a, there's an exchange of money, but the much bigger cost to adopt any of these things and and and I'll talk about in a second, but it fits into this, um, the same way is it's a, it's a complex multi stakeholder architectural decision.

So if you think about the time that goes into making that choice, and then if you think about the, you know, the number of hours or or the number of people that you're going to invest in that once you've made that choice, that's not a small decision for a lot of companies. .

So with GraphQL, that's, that's really been, um, for us, the the the reason that we went in the direction we did with a a company that's built around this, is that we just asked a very simple question. How do you get something like this adopted?

I can give you a a really compelling technical reason why it's way better to have a graph and write a query, than to write a whole bunch of procedural code every time you want to make a new application experience.

But in practice, how does that get adopted? And if you really pull the thread on that question, a lot of interesting stuff comes out. Who owns the APIs in a, in a typical enterprise? Who makes the decisions about the architecture?

How do you balance, you know, an exact that owns road map, somebody who's trying to ship products? They have a tough job.

Like the VP of Engineering job at a company, I think is, is maybe the hardest job today because on the one hand, you are under enormous pressure to ship quickly. This is, this is not the IT of 20 years ago.

If you sip slower than your competitor, that's probably like the end of your viability as a company, right? Like, if you're a, a retailer and you can't keep up with the modern expectations of a, you know, consumer that wants to buy stuff online.

I think the the customers are going to walk. They're going to go to some other company. So you've got to ship fast and good, right? But, but, but, the other half of it is like, you can't mortgage the future to solve your problem of today.

So if you race to ship a product, but in doing so, create a big security vulnerability, you're going to get fired. Yeah.

If you race to build a product, but then you come into work Monday morning and discover that, um, Amazon shipped Alexa, and you need a voice app or OpenAI shipped GPT and you need an agent or whatever's coming next, right?

Um, if you didn't prepare for that unknown future architecturally, if you've painted yourself into a corner, you're you're in trouble. And so you excuse me, you're a real caught between a rock and a hard place.

Um, and again, the the the the consequence of that is like you're you're going to want help. You're going to want more than just a raw piece of technology.

You're going to want to have a plan, you're going to want to have some, uh, some, some end end integration, in practice, we call them the ities, right? you need the, um, the observability and and the security and and all of the the auditability of of a solution that you might bring in.

And so that's for, I think infrastructure at least, um, the heart of the the, the way that you go from a piece of open source that makes technical sense and has a lot of technical excitement behind it to something that makes business sense and can actually be adopted at scale.

And also like there's always this concept, right? Like you're not just adopting a product when you're building like I'm an enterprise company or I'm a business that is adopting any open source technology, I'm just not adopting a product.

I'm adopting a certain level of risk that comes with it. And that's where we you have all these agreements, you have lives from both sides signing, you know, if a data privacy issue happens, who's responsible for that?

You know, you know, all these things are happening. So when you're trying to build a serious business, you have to all, you know, consider all these risks, um, you know, whichever type of that is.

And the biggest risk by far is picking the wrong technology. Yeah. Like think about the cost of getting that wrong.

Like if you if you adopt a database and it turns out you pick the wrong one and five years later, there aren't really any users and the open source project is is, you know, on life support and there isn't a vendor that can really help you.

Like now, now you're in real trouble. Now, now you have a migration. Yeah.

And And not what much not to do what's going on Meta, but like that that's the problem I had with Lama C is open sourcing because, yeah, you can open source a model, but then if I'm a when someone building on top of a model, I I want someone to provide the model.

I want someone to host it and give me an 99.99 reliability so that I can, you know, build something on top of it. Uh, so And you see this on Dynamic between open source and close source. You see this across the stack.

Like, yeah, maybe 10 or 12 years ago, a developer would have started by asking, well, like what's open and what's closed and like I I want to avoid vendor lock in or I want to avoid like, you know, being um Oracle in particular, left a lot of people feeling like we should be very careful about buying proprietary because, you know, the Oracle rep shows up at renewal time and keeps raising the price and what are we supposed to do?

Uh, and and now I think it's a little different. I mean, that's still true, but there's so much stuff to buy across the whole stack. You don't have a lot of time to do a deep analysis of any of it.

And again, the the biggest risk is is getting it wrong. I mean think about how fast AI is moving.

So one of the, one of the things you keep seeing is this sort of preference for, for the prevalent and you're you're probably going to be in good shape if you go with the market leader because that means you're going to be able to hire people who know the technology.

It means there's a very good chance that the technology is going to mature quickly enough to meet your needs in the future. Why is that?

Because there's a lot of people using it and that means there's a lot of investment going into it and so on and so forth. And it's a virtuous cycle. So the, um, you know, the and that's the pitch I make for GraphQL whenever I'm talking to a company.

Like you, you have an API strategy to decide on. You ought to start from the premise that that like picking the one that a lot of developers like that that clearly has um, uh, a vibrant, you know, user community around it that's that's well adopted.

That's a safe choice. Yeah. As as opposed to a proprietary alternative that, you know, might have some technical benefit, but ultimately just just doesn't have the the breadth of community.

I have a view on like the whole full stack evolution and I want to get your thoughts on that.

Is like are we making the full stack development more complicated or less complicated or um is it complicated enough for the uh, you know, trade offs that we want to make. Like I I feel like we're making things more complicated.

Like to stand up a full, uh, like a scalable web application. Uh, I want to get your thoughts. When I grew up writing software on a Commodore 64, it's definitely gotten more complicated. And it's and it's it's all across the stack.

Like, like, you know, microservices make a lot of sense because you need a way to scale your engineering efforts and and and seeing an architecture that lets thousands of engineers all work on, you know, separable services.

That's all absolutely correct. And yet, what it means is it, it drives the need for, um, well, you're going to need something to manage all those processes. So there's your whole world of cloud native and Kubernetes and so on.

You're going to need, uh, a way to orchestrate API calls across them. There's your GraphQL Apollo story. Is Apollo adding complexity when you bring in a query planner and and like start writing GraphQL queries?

I mean there's an argument that yeah, it absolutely does. On the other hand, um, I think each of these layers of the stack, when they're done right, does, um, add value, right? It lets you go faster.

What, one of the things that, that you find in, in a good architecture is that you, you want the property where the more you build, the more valuable the whole thing becomes or the faster you can go.

You you can imagine like an exponential curve where if you chart the energy input on the x-axis, the Y axis ought to go, um, geometric in some way or or exponential. Some technologies don't feel like that.

They look like a log curve where you keep putting energy in but it somehow just perversely like slows you down.

Or if you look at it the other way, you need more and more calories, more and more person hours to get the same amount done in in in in a world where you've built a lot.

I think there's a lot of uh, distance between the Y-axis and where it starts to become geometric again graph, like where the early investment is like a.

You close to the x-axis where you're like putting a lot more energy in and you're always like thinking about, okay, in two years this makes sense, in three years this makes sense.

And that's, that's really the complex part of this where it's like you can't get something started really fast because you're thinking of the output for two, three years down the line and how like the, you know, for the database example, right?

You can't make a wrong decision for a database because that will not show up right now, but it will show up like three, four years.

It's it's so, it's so gnarly because a lot of technology decisions boil down to do do I want the quick result today and I know I'm creating debt for tomorrow or do I want do I want to set myself up for a bright future?

And, you know, some of this just goes to like crack open the Wall Street Journal and check the interest rates today and that'll, that'll guide you in which direction makes sense. But like it's, it's a hard call.

And I think the I mean for us, the way we look at it is our job is to try to square the circle. Like, you know, Kubernetes was really complicated for a really long time.

But slowly but surely, uh, a lot of this is the hyper clouds, a lot of this is just the maturation of the, you know, CNCF stack, like it's gotten easier to use where I'm not, you know, I'm I'm not coming in with a a 10 month effort before I've got my first process running.

Um, uh, and and now you see like all the benefits of well, if we know everybody's on Kubernetes even at a small scale, now we can use it as a packaging solution for software and so there's, there's a whole bunch of things that fall out of that as you make the stuff easier and easier to use.

That's been a big priority for us at Apollo. The knock on GraphQL is there's a lot of upfront setup work to build, we call it a schema. It's it's the catalog of all the APIs you have and how they're connected. Once you've done that, it's wonderful.

But to get there is a pain, and a lot of our road map over the last year has been attacking that and making it really easy, really fast to be able to, um, get to that point where you can write a query and it's valuable and you see the benefit.

Because it's just a tough conversation if you have to make that trade off. Like most people in 2025 are are going to pick the solve my today's problem and I'll worry about tomorrow tomorrow.

If If you have a, like a, if, if you have a small company which is like one or two APIs and you're consuming couple of APIs, I mean, realistically then know like companies which are come consuming to three companies.

But for the sake of the argument, like at what point does, you know, adopting GraphQL makes sense for a company and what type of customers do you have today?

Yeah, I mean the reason I would say it makes sense is that if you look at it from the client point of view, when you're using GraphQL and React, let's say, all you do is write a query in your, in your JSX.

Like it's, it's just in your component and that's it. Like, from the API point of view, like one or two REST APIs, what's the big deal, right?

Like it's it's it's fine and and um, usually if you're talking about a company at that stage, it's not hard to go in and change those REST APIs if you don't like something about them.

So if the payloads are too large and you really want to improve the latency of your user interaction, you can go in and improve the REST APIs.

When you're talking about a company with 10,000 REST APIs, you're also probably talking about a company where there's a lot of different users of those APIs and it becomes very difficult to go in and change them.

I don't I don't I have no way to know in a REST API what fields are being used. There's there's no information about that. I'd have to crawl the code bases. Um, so there is an argument for it.

But again, you're, you're having to explain it sometimes to, to people for whom it's like, well, I can just change all the stuff I need to change. The thing that's really interesting now is agents. Because everybody wants to use MCP.

Everybody wants to have some kind of an agentic experience on top of those APIs. And the question is, how do you get from here to there? And it turns out GraphQL is a fantastic fit because what does GraphQL do?

It lets you, lets you describe just the fields you want. It lets you write a a description of how like, you know, in in plain terms, how do you define an MCP tool?

Well, you could write a server, you could write a whole piece of code that calls those APIs and does a bunch of procedural work. But it turns out you can also just write a GraphQL query in a minute and you're done.

And so, um, it shows that that GraphQL really at its heart is an orchestration language. It's about, um, all kinds of stuff you might want to do to transform something, to change protocols, to filter.

Um, and I, we're excited about agents because it puts those needs front and center in people's minds instead of it being something you don't, you don't really think about too much because like you're, you're just used to writing apps a certain way.

Yeah. Um, talk to me a little bit about size and scale. Like how many customers do you have? Uh, like what is the scale of Apollo today? As a business. GraphQL is used in probably about half of the the enterprise world.

There's a bunch of ways to get to that data.

You know, we see it because we're the provider of a most of the standard open source libraries, like if you're using Apollo Client, um, if you're using Federation, you're you're probably running Apollo code.

Um, you know, commercially we focus, um, in the past at least, we've focused on larger companies and the reason is very simple. Graphs have a network effect. So they are most valuable when they're large.

And I alluded to this before, but I'll I'll give you an example. Um, so we have a lot of retailers, um, on the graph. Think about you you go to a an online store and you're looking at a product on the screen.

And one of the things that you want to know is like if I buy it, when is it going to show up on my doorstep? Like I need it for this weekend. When is it going to come? And, um, I don't know.

I've I've gone through this where like I'll half-heartedly go through the checkout flow sometimes just to like I'm I'm not sure I want to buy it yet, but I need to get far enough along where I've given it my zip code and whatever else that it will tell me, you know, when it's going to come.

And if you think about it, like you, you really want to put that on the screen. You, you want to be saying arrives on Friday, but how do you do that? That's a that's a ton of API calls under the hood.

You've got to call a bunch of, you know, inventory APIs to figure out which warehouse it's going to come out of and and what's in stock.

You've got to call the APIs of your shipping partners to figure out the shipping cutoff times and the customer's destination address. That that gives you, um, different options for, for arrival time.

Then you've probably got a business decision to make around calling a a loyalty API to figure out if this is a new customer or a member of our like customer loyalty program, like like Amazon Prime or something like that.

And maybe you want to optimize for the shipping time, maybe you want to optimize for your margins.

So if you think about just like arrives on Friday, like 20 characters that that you want to have on that product page, there's maybe a dozen API calls under the hood.

And it's the kind of stuff that is so it's trivial from the point of view of the user's experience, but explains why this stuff often isn't built or takes months and months to ship. Like maybe those APIs are slow.

Maybe now you need a an async story so that you don't block the rendering time of the page because we know that like in in e-commerce every millisecond matters.

So maybe you, maybe you go build a message bus somewhere in there so that you're, you're able to flow this information in in a way that doesn't harm the overall user experience. And this this story just goes on and on and on and on and on.

So, um, we find in in larger more established companies, um, you know, retail, media is an example. Um, you know, the New York Times is a huge user of of GraphQL.

And if you think about them as an example in media, that that a long time ago looked like a content delivery business where I'm going to read a newspaper story in my web browser.

But if you think about a modern media company, you've got hyper personalization.

You've got, I mean, New York Times has gaming, they've got the athletic, they've got all kinds of properties that they've brought together to form a an engaging user experience. It's just a completely different kind of business.

Um, and more and more it's subscription driven rather than ad driven. So, um, those sorts of uh, larger companies often where you've done M&A in the past and so you're your your underlying systems are really heterogeneous.

You did the acquisition for some kind of synergy between the products, but like that was the whole point. You got to bring the products together into into a single user experience.

That's that's where we find GraphQL is, um, historically adopted the most. But again, agents are changing that because with with agentic AI, we're finding a lot of excitement and hunger around GraphQL at companies of all sizes.

Um, think about the energy behind MCP and think about what fraction of startups that have an MCP server have had a rather embarrassing security problem that they've had to acknowledge, right?

Like it's it's there's a lot that goes into making a proper agentic user interface or an API interface underneath that and, um, uh, and so for us that's, that's changing the mix of the business a lot.

And how how do you, uh, go about acquiring customers or I guess it's it's a two part question. Like how do you, uh, you know, acquire new customers, but also how do you make sure that you're marketing continuously to new developers, right?

Because I feel like it's sort of like you have to make sure that you are the go to product for developers so that when they go into different companies, they pick GraphQL Apollo GraphQL versus another technology.

Yeah, I mean, I think for most open source companies, certainly for us, um, open source is an important part of the funnel. And, um, the reality is in this day and age, development teams are going to make the technical decisions.

And and they'll have to, you know, I I said at the start, if if you're in a larger company, I think a good engineering leader or a good architect is going to see the a GraphQL investment as a strategic investment because it's it's it's going to spread.

It's there's a network effect to the graph. So you're going to want to think through all of the decisions and and the plan for how to roll that out. But kind of at the heart, when you talk about acquisition, like how did all that start?

It starts with a developer who reaches for something that they've heard of, that makes sense, um, that they can try quickly and open source is a great vehicle for all those things. So that's, that's really the heart of of how all this stuff works.

It it starts with a React developer who who reaches for Apollo client. It starts with an MCP developer who wants to, um, you know, very quickly define an agent declaratively, um, on top of their API instead of having to write a code base.

And and then you can, you know, you can build from there, but but at least for us, um, that open source and the content for people that want to use that kind of early stage development tool, um, is is the is by far the most important thing.

You recently, uh, transformed from being the seated of the company to a CEO of the company. How much does your focus on things now change? Right? How does that evolution between working as a CTO and CEO being?

I think it changes a lot, changes nothing, um, depends how you think about it. I mean, I've always felt that the most important thing is on the business

---