Orchestrate all the Things - Apollo GraphQL announces $130 Million Series D Funding, wants to define its own category. Featuring CEO & Founder Geoff Schmidt

Episode Date: August 17, 2021

GraphQL is a specification that came at just the right time to address an age-old issue in software engineering: service integration. Apollo's implementation is seeing lots of traction, and it just got more gas in the tank for its grand vision that goes well beyond integration. Article published on ZDNet

Welcome to the Orchestrate All the Things podcast. I'm George Amadiotis and we'll be connecting the dots together. GraphQL is a specification that came at just the right time to address an age-old issue in software engineering, service integration. Apollo's implementation is seeing lots of traction and it just got more gas in the tank for its grand vision that goes well beyond integration.

I hope you will enjoy the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook. My name is Jeff Schmidt. I'm the CEO and co-founder of Apollo and Meteor.js before that for the Meteor users in the audience. And yeah, you can find us at apollagraphql.com for all your GraphQL needs. And George, you know, I know you've done a lot of coverage of graph databases.

I think one of the most interesting things here is kind of the distinction between what's going on with GraphQL and graph databases, which I know you've written about before. And we really see the development of the graph as a whole separate layer of the stack that's separate from the storage layer and i think one thing that's really cool here is um you know we're now seeing a lot of different threads come together uh in terms of what's happening the

open source role what's happening in the commercial world for us and now with the fundraise i think there's a lot of validation of this idea that there is this new layer in the stack called the graph that's separate from the persistence layer. Yeah, you're actually quite right about pretty much everything you said, I would say. But let's take it one step at a time. So as a sort of welcome, well first of all thanks for making the time to connect today and there's a lot to discuss as you kind of hinted in your introduction. I'd like to start with a little bit of a more formal, let's say, introduction like officially welcome you and all that. Just let me say on my side that well the occasion today is that

you've raised a serious amount of money which as you also said is as is always the case I mean besides the money itself which is always good and useful I think probably for most founders that I've talked to what they're mostly happy about is the validation that this signifies and this vote of confidence from investors, let's say. So we'll get to talk about that. But actually, before we do, I was kind of hoping we could maybe do a little bit of rewind because I happened to read an article which wasn't exclusively about you. It was a Business Insider article recently and it was about open source visionaries, let's say, and what they're doing with their companies and so on.

And so by reading that I realized that you have a sort of unconventional background in a way and you've also been involved in open source startups before and so I was wondering if you'd like to say a few words about your personal journey so maybe a little bit about your previous startup and what inspired you to start Apodo basically because I think this will also shed some light on the bigger picture. But let me tell you what's really important to me. What's important to me is we've created all this amazing technology and I've had a long history you know I've had a chance to be involved with some amazing things that have happened in technology. I've created on people and has on society. And, you know, I do come from a little bit of an unconventional background where, you know, I didn't follow the normal path of going to school and, you know, maybe growing up in a place where there's a lot of people around me that were super into technology.

You know, I got really fascinated with everything you can do with computers, but where I've come to at this point in my life, I'm so much more interested in the impact it has on people. And I think that's almost, as much as I love all of the computer science that went into Apollo and Meteor before that, what really is intellectually interesting to me at this point is all the complex dynamics about how technology is used by people and how it impacts people's lives. And so Meteor was a great example of that. Like we started Meteor with the mission of making app development radically easier, faster, and more accessible.

We saw there's so many cool things you can do with the internet, so many cool things you can do with all this amazing technology it's developing. But if that's too hard for people to access, if it's too hard for people to build the apps that they use every day, then you lose so much of the benefit there. So we asked the question, how can we make app development really, really easy? And that led to Meteor. And the challenge with Meteor is you could only use it to build new applications. We learned a lot from it. Meteor became one of the top 10 most starred projects on GitHub.

We launched Meteor 1.0. I think there were local Meteor meetups in 134 cities around the world on the same day. But we saw that there was a chance to have a much bigger impact if we could build a version of that technology that would let you integrate with any backend, any front end. So you could use it not just in new apps, but in existing apps as well. And that's what led us to Apollo. I mean, I don't know, I can go sort of direct me wherever you want me to go. I'd love to talk about what I'm really passionate about, which is making technologies for humanity and helping app developers do that.

Yeah, that's great. Actually, that was precisely what I was looking for, basically the connection between your previous venture and starting Apollo. So basically, what triggered you to start Apollo relatively early in the lifetime of GraphQL? And what was it that you saw in the technology? And what was the vision, sort of?

And I think you hinted at that already. Yeah, and what we saw with Meteor is it was a super great experience for people who are building new applications. But there was something missing, which is the ability to connect to all the data sources that exist and all the services that exist in the cloud. Because it used to be apps were comparatively simple. You had your app. I mean, you had like a web server that connected to a database. And then you delivered the front end into a web browser. But what's happened is the landscape has gotten so much more complicated. It's not just one database so for example meteor it was based on i mean you typically build a meteor app just on top of

mongodb we found that people are bringing together especially the enterprise they had many different microservices they wanted to connect to they had many different databases they're running their applications in multiple clouds and then on the front, it also wasn't just a web browser. It wasn't even just a web browser and a mobile app. We saw that people are building apps that run all over the place, that run on a set-top box, or they want to build apps that run at the point of sale in their retail establishments. There's more and more places that people want to build these digital experiences. And what we saw with Meteor was that we needed to take everything that we had learned that made Meteor so good. And so much of that was really around how data is moved between the server and

the client. And we needed to make it work in that world where you have so many different things going on in the back end and so many different places you want to deliver your application. And so we started out building what was originally going to be a new data system for Meteor. And so for us, like the work on this actually predates even us starting to use GraphQL, but we realized pretty quickly as we were working on this, Facebook released the specification for this GraphQL query language. And GraphQL is just a query language, just like SQL is just a query language. GraphQL isn't a piece of code that you can run. You need an implementation of GraphQL. Just like for SQL, you might use Postgres or you might use MS SQL Server.

There's many different SQL databases. There needed to be an implementation of a data system that would use GraphQL as its query language. And so we went ahead and adopted, we thought this language, GraphQL, is a really great query language to use for what we were building. So we realized that we needed to build a version of what we've done with Meteor that would work with any backend, would work with any frontend, would work at the scale of the world's largest applications, would work on the scale of really large teams, hundreds or thousands of developers all working on the same connected set of data,

and can still deliver absolutely world-class experiences. And we realized that GraphQL is the right query language to use. And so we released really, I guess, the first components of Apollo, like the first version of Apollo client back in 2016. And since then, we've really just been following whatever the users and whatever the community needs and building piece after piece of that stack, like the connective tissue to connect all the services to all the front ends, and really focusing on making it super easy to use, very broadly applicable, and also incrementally adoptable. So you can bring it into an existing app really easily instead of having to build a new application like you did with Meteor. Okay, great.

Thanks for the introduction, actually. What you just said points to a number of different directions and I'd like to explore them more if at all possible. So you quickly referred to Apollo's technical architecture and how it has evolved and this is something

I would like to cover actually and I think many of the people in the audience would like to know more about it. Obviously we can't go into too much detail in the time we have. It's just an overview, let's say, of the architecture and how it has evolved and why, most importantly, perhaps, why it has evolved the way it has would be interesting.

But actually, let's start with something a little bit more abstract. So in your introduction, we talked about what you called the graph. And to me, well, being who I am as basically someone who's really interested in anything graph-shaped and graph-related, I can relate to that. But I'm not sure it's that obvious to everyone out there. So my interpretation of what you mean when you refer to the graph is basically this mess of well all these API

endpoints that Apollo and what solutions like Apollo help people connect to and it's really a mess so you know if you look at it from a distance it's a graph of APIs that this query language or this specification helps people leverage, basically. But, well, my question to you, basically, I guess, is, well, how do you define what you call the graph and how do you explain that to people? Like investors, case at point, do they get it? Is it something that you see resonating with them? Sure.

And I think the easiest way to understand this is to think about the perspective of an application developer. So there's so much attention that's been given to the back end over the last five or 10 years, going from what used to be a web server and a database to this whole, you know, microservice fabric is an architecture that many people have now. But what that's done is it's created a lot of complexity. And at the end of the day, the reason why we do all this work, the reason why we build all of these services in the cloud is so we can build apps. It's so we can make all the services useful to people for particular use cases. So look at this, all this complexity now from the point of view of a product developer. If you're building a product, if you're building microservices on the backend, you really want things to be siloed. You want to have your product service over here and your customer service over here, your inventory service over here, your shipping service over here.

You want each of these things to be very reusable, modular, independent, so you can combine them in any way you might need in the future. And your biggest concerns are you want them to be scalable, you want them to be available and reliable, you want them to be secure. If you're looking at the world through a backend point of view, you end up with one architecture that's based on separate, scalable, siloed services for each thing that your business does or that you want to do on the backend. But that's really different from the needs that a product engineer has. Product engineers, our job is to go create those experiences that people use every day. And that means that we need to combine all of those different things. So if you think about a typical screen in an app, just think about like a typical e-commerce app,

where you have a screen in the app that lets you purchase a product. You have to combine many different services. In a simple app, it might be half a dozen different services, but in a more complex environment, it might be hundreds. There's the product catalog, and there's the images, and there's the reviews, and there's any promotions we're offering. There's your shopping cart. All of those elements have to be woven together to create this, even just a single screen in your app. Any given screen in an app is like that. It's usually pulling together not just many different sources of data, but really many different services. Because each of the things I listed, you know, for the most part, they're interactive services, like your shopping cart, you're putting

things in, you're taking things out, you know, you're computing sales tax, you're computing shipping, you're computing recommendations. So the challenge that product engineers face is as there's more and more functionality in our app and more and more complexity in the backend, how do we integrate all those things together to get one experience? And in the past, what we did is we had these point-to-point API technologies like REST APIs. And the problem with those is that they are more oriented around, like if you look at the backend services APIs, they're oriented around just looking at one piece of the puzzle, just looking at the product catalog, just looking at the inventory. And so we have to put them together in a different way to build our applications. We can't use those backend APIs directly, directly typically so what usually folks end up doing if they're not using the graph is they have something that might be called a back-end for

front-end layer might be called a experience api it's basically a tier in your architecture that's a whole lot of code many many like often millions and millions of lines of code at scale where all it does is it takes those APIs that are coming out of the backend services, and it combines them in different ways. It reformats them and joins them to create the APIs that product engineers need to build their apps. And that step ends up being a huge drag on productivity because every time you change something in the app, you have to go write more code in order to integrate the backend APIs you need in a form that can be used by the front end. And I say write more code because it's kind of a write-only situation. Once you create these APIs, it's really difficult to remove them. You often end up with many different of these

front-end APIs that are very, very similar, or maybe even identical, or give overlapping views of the same data. Because it's tough to identify who's using an API, whether you could remove it. It's really tough to go audit all those billions of lines of code to make sure it's all secure and performant. And for app developers, it really gets in the way, all this integration work they have to do. So the idea of the graph is, what if we gave product engineers what you really want, which is the ability to access all of those services on the back end, wherever they may be, whether they're all in one monolithic server or whether divided off across a bunch of different microservices. It lets you access that with one interface where you have one view of all the data and services, and you can query it and access it just like you'd access a database.

So what we're doing is we're creating this virtual graph layer, and we call it a graph because it's connected. Like I have products over here. I have inventory over here. I have orders over here. I have customers. I have reviews. We're going to map out all the links, all the object references between those different business objects. And we're going to put a virtual view on top of all those services.

So a customer might have 200, 300 attributes or more in a larger company. Those might be coming from many different microservices. We're going to create an abstraction layer that hides all that complexity. So you don't have to know where that data lives and how to access those services. In fact, it could change from day to day if you refactor a monolithic backend into a bunch of microservices. We're just going to give developers the ability to freely access and query that data through this virtual graph interface. So it creates this situation where now product engineers have this incredible ability to search everything that exists in the graph, no matter which service it lives in. If it's inside your company, potentially, even if it's a third-party SaaS service, and you can freely access it all without having to know

where it's coming from and how that access is done on the backend. And I can go into the architecture of what makes that possible, or I can go any direction you want from here. I guess you did ask about investors. I would say, you know, what investors first saw was the rise of GraphQL. There's an incredible number of people that are using GraphQL in some way. 30% of the Fortune 500 use GraphQL, actually use Apollo, or more probably. There's 2 million downloads a week just of Apollo client.

It's gotten really huge. So that's the first thing that investors noticed. And they also noticed that more and more people are, I think it's like 83% of developers say that they either use or want to learn GraphQL in a recent survey. And so that's the first thing investors notice. And that causes people to ask questions. Hey, what is this? It's clearly a big developer movement. What's driving this?

And it's really when investors speak with the people that have used this at a little bit of a larger scale, not just to build a single application, but when more and more enterprises are rolling this out in a strategic way, not just to say, hey, this is an individual library that you can add, but this is actually going to be the basis for how we connect all of our front ends to all of our back end. Because putting this graph fabric in place, using the graph, not as a way to store data, but as an abstraction layer on top of all of our microservices and databases, this can let us move much, much, much faster. If we want to go from being a product company to a platform company, if we want to build an omni-channel customer experience, if we want to respond to competitors faster with much broader and deeper products that we deliver across a lot more channels, which has been a or if we want to respond to something like the COVID pandemic, we need to do more stuff online. We need to rethink about how our business works and how we interface with our customers. What investors notice second is how often this technology is involved in these transformational enterprise initiatives and how quickly it grows inside of a company. And then the pieces start to fall into place when you realize, you know, just talk to some of our users. They'll tell you how they found that their UI

developers are spending only a third of their time building user interfaces and how the graphics the problem. And that's when investors started to get really excited when they understood how big of a change this was going to represent, how it's really a new layer of the stack. It's a layer of the stack that's getting inserted in between all the front ends, like your web browser, your mobile apps, your IoT devices, and then the business logic, the microservices. It's the essential connective layer that replaces the millions of lines of back and front-end code that you otherwise would have had the right would have slowed you down a lot. Okay, so that's a grand vision to execute on and we will certainly get back to some specific actually technical questions I have regarding your architecture and its evolution. But before we get to that, I would like to ask, well, first of all, I know that you mentioned, well,

doing this at scale, basically. And I know you have some quite high profile clients, and I'm sure that, you know, doing it at the scale that's required for them must be quite challenging. So I'd like to take a step back, however, and ask you a little bit about the company specifics and actually funding specifics as well, because so far we haven't referred to them at all. So, you know, things such as, well, your headcount and the evolution of your headcount and how much funding you actually raised from whom. And, well, what the vision is on executing, but what the vision is that you're trying to execute on as a company. You sort of laid that out already in somehow technical terms,

let's say, what you're trying to achieve. But how you're actually, what are the intermediate steps, let's say? So what are you going to be using the funding for? And what's the timescale? Of course, we think every product engineer deserves a graph. Because product engineers, the way I see it, are the primary value creators, in the sense that I mean, in the following sense, we invest a lot in our back end. And that's critically important.

But it's only when you build an app and people are able to use the app, that's what creates all the value of all the investment we make in technology, when you can really bring it to a real human being and make it useful to them. And we see how much time product engineers, how much their time is wasted when you have to use these point-to-point APIs like REST, you have to build these backends for frontends. We want to give them the tools they need so they can be super productive and have a bigger impact. So we want, we think every product engineer

should be able to use a graph to access their services. So that's our mission. That's what we're going to do with the money we've raised. So our last round two years ago, we raised right around $20 million. This new round is $125 million. So, and it's, and it's a, a little bit north of a one and a half billion dollar valuation, which is, you know, just it's a nice, it's valuation isn't everything, but it's a nice validation point that the investors out there in the market do see the commercial potential of technology. That's about a 10x up round from where we were two years ago. So it's, it's been a lot of things have unfolded very rapidly over the past two years. So what

that means to me is, it's the gas in the tank we need to continue serving our community. We are where we are because the motto of Apollo Client from the very beginning was by the community for the community. We want to listen carefully to what app developers need and we want to build it for them with the goal of making their lives easier so they can have a bigger impact on the world. I like to say that our mission is to help app developers help the world. There's so much potential in this technology. We need to do more to empower app developers so that they can go out there and build the apps they're building and have the impact they're going to have. So we're going to invest, continue to invest up and down the

stack. We're going to continue to make large investments in the entire open source stack from Apollo client to Apollo server to the graph router that sits in between them. We're also going to continue to build out the enterprise offering because people are running Apollo at greater and greater scales in the enterprise. And there's many components to that. There's one component of scale that's about the technology, how many queries you can run and how many milliseconds and how fast they execute. There's another component of the scale that's really about the complexity of your graph. How many different services are on the graph? How many different object types do you have?

And when people go from maybe 10 object types in their first implementation to 100 to 1,000 to 10,000. We're starting to see these larger and larger graphs. You need excellent tools to search and discover and navigate larger and larger graphs. I think eventually we're going to have a global graph. So all the work we're doing to put these pieces together is super valuable as part of that larger path as well as serving our enterprise customers. And the third aspect of scale is people scale.

It's really different when you have five people sitting in a room that are all working closely together on the same release cycle, building the same few features, versus when you have 10,000 developers that all have their different decoupled development processes, and you have people that will never meet all working on the same graph and contributing services, using services. There's a lot of workflows and business processes and security and change control mechanisms that you have to build at that scale. What we're doing is we're staying close to all developers that are using the graph and really trying to understand their needs. And everything that we do comes back to how we can better serve the community and bring a graph to every developer

on top of all of their existing backends. One comprehensive graph where they have one place that they can go to discover and query all the services you need to build an application. Did I cover everything? Anything else? No, that was great.

Actually, you gave me a nice segue for the next question that I wanted to ask you, which had to do with basically coming back to the technical architecture. But you also touched upon another point which we didn't mention so far at all, the fact that you are also an open source company. And so I think that ties in nicely with the architecture question because I was going to ask you basically, if you can quickly refer to the components that make up the Apollo architecture

and just a quick overview of what each of them does and how they all fit in together and sort of tie that to the enterprise version that you have. So which of those components are in the pure open source play and which one of those are in the enterprise version? Sure, of course. So the core components that make up the system, there is the, so to access the graph, you're probably going to use a client. So we have a GraphQL client called Apollo Client, shockingly enough. And you don't necessarily need a client to access a GraphQL graph because it's very easy to just hit an API endpoint, send a query, get a result.

But there's so much more that you can do when you have a smart client in the mix. And you can locally cache the data that's been returned from the server. You can do that in a normalized cache so that you can run other queries and they'll hit the cache locally. You can bind your UI directly to this cache. So basically what it all adds up to

is the ability to build a UI and then just simply say, insert this data here, just write the GraphQL query and have the client do all the work of getting that from the network and inserting it right in the UI wherever you want. And Apollo clients available for web, so for React or whatever your JavaScript UI library of choice is, as well as for iOS, as well as for Android. So however you want to consume your services, there's an Apollo client version for you. Then you also need a way to get your data and services onto the graph. There's a lot of different ways to do that. There's a lot

of great libraries, you know, GraphQL, Java, like, you know, take your pick, connectors for every language. But we have one that we think works really well for a lot of people to get up and running with the graph really quickly. And it's also versatile for a lot of different situations. And that's called Apollo Server. Apollo Server lets you very quickly get your services and data wherever it's coming from onto the graph, just using JavaScript or TypeScript. It's a super easy experience. You just write out your schema. You say, hey, I have a user object and they have a first name and a last name and I have a newsfeed story

and it's got a title and a body and then I've got comments. You just write out these schemas and then you just write a couple lines of JavaScript in the form of what are called resolvers and you can use anything that exists in the JavaScript ecosystem. Any NPM package you can find, you can connect to, which is just about anything, you can connect to anything you want

through that. It's not the only way you can put your data and services on the graph, but it's a really great way to get started and also scales to the most complex use cases you can imagine, is what we've seen in the field. Okay, so I've got my client, I've got my server, how do I connect it to? You need what we call a graph router. So the graph router is, you know, a database contains a query planner, it contains a cache, and then it contains some sort of persistence way to store that data. A graph router is kind of like a database, but without the persistence. It's got a query planner. It's got all the policy and access control and security. And it can have different types of caching semantics, but it doesn't store data.

Instead, what it does is when you're sending in a query from the client, it goes to the graph router. And then the graph router uses its query planner to say, okay, well, if the developer wants to join this data and this data and this data, I'm going to build a query plan. And the query plan is going to involve not reads and writes to disks,

but API calls out to all of your other services, which can be Apollo Server or any other GraphQL-based connector. So the graph router, it's kind of like a Cisco router for your graph. It creates this network or this topology so that requests can be broken into pieces and all the security and execution rules can be applied. And so our current graph router is called Apollo Gateway. It's something we're going to be investing in a lot over the coming years, making that graph router better and better and better, making the execution more and more sophisticated, adding more and more security and policy controls, all which is driven by our experience,

deploying this both, both helping people get started really quickly, and also deploying it at massive scale in the enterprise. And the technology that enables that is Apollo Federation, which is an open standard, so that you can participate in this federated query execution, as well as a few other open standards that we have. And then the other piece is, so what I've described so far is really the data plane. It's how a byte goes from a client to a server in form of a query and then how the result goes back. You need something to manage all these components.

And that's why we have something called Apollo Studio, the heart of which is a schema registry. So if the graph router is like the Cisco router for your graph, it's like the Cisco router for your graph, it's like the backbone router on the internet that moves things from point A to point B and figures out how to get everything where it's going. The schema server is like DNS.

It's the map of the graph. It says, hey, here are the types that exist. Here's the access control rules around that. And here's where the backend services live. And here's how we manage that fleet of growing or shrinking clusters of graph routers that are used to execute those queries and keep them equipped with the right configuration, security, observability, et cetera. So the schema registry is the source of truth for your graph. Then we

build all sorts of things on top of that in the larger Apollo Studio SaaS offering. So we have an amazing tool called Apollo Explorer, which lets you just point and click to build GraphQL queries, while also giving you the ability to search and navigate absolutely huge graphs and do the query plans as you type. Or you can get a lot of that same information right inside Visual Studio Code. There's a great integration where, as you're typing the GraphQL query, you can even see the predicted latency, how long it's going to take to execute. There's a set of great CICD integrations. So, if I'm making a change to the graph, how do I make sure that I'm not breaking somebody

else's change that they're making at the same time? How do I manage multiple versions of the graph as I'm rolling it out? How do we make it so that if I'm looking at a particular piece in the graph, I can track that back to a particular human being? So if I need to talk with them, even if the graph has gotten very big, I know who maintains what service. And I know who, or if I'm a backend team and I want to deprecate a particular field that's being served by a particular service, how do I figure out which developers are using this? Which versions of which mobile apps that we shipped and which geographies are driving that?

So those are the key components. Apollo client to access the graph, Apollo server, or your choice of connector to connect your data and services to the graph. The graph router is the execution engine in the cloud that, you know, that plans the queries and, you know, turns those client queries into calls into the underlying services. And then the schema registry is the map of the graph on top of which you can build all sorts of business processes and tooling to make your life easier and manage the collaboration around very large-scale graphs so that you can be changing a graph a thousand times a day instead of once every two years like you would with the REST API. Okay, thanks. That was a nice overview of the architecture.

And well, I guess we still have a few minutes left so I'll try and squeeze in as much as possible in the time we have. One of the things I wanted to ask was basically let's try and tie that in as well to the future plan so where you're going to be focusing your innovation efforts and as far as I knew and I think what you just mentioned sort of validates that. It seems to me that the one part of your architecture that has the most complexity is probably the graph router, where you need to write queries, optimize them, direct them, and so on. So I guess perhaps at least part of your effort

would be focused on that. Because as you also said, as graphs grow so does complexity and it's going to be more and more challenging and that's something a new addition to your team, Josh McKenzie, who's your current VP of Engineering, he also mentioned that to me in a previous discussion we had and he said that well perhaps we should be focusing our attention on actually serving, developing and implementing actual graph algorithms to be able to do that. And I guess that's maybe one area.

And I was wondering if there's other areas that you're going to be focusing on as well. Yeah, you've touched on some of the key ones and some of the things that are my favorite. You know, we are, you know,. Our graph processes billions of queries a day, so we've been able to see what this technology looks like at scale across all the axes of scale that I mentioned. Both scale in terms of how quickly and how efficiently you can execute queries and how you can manage very complex graphs as well as how you can work help enable very large teams to collaborate on the graph so we're working on the scaling the scalability of that core graph router fabric across all those axes based on the real world needs that people

have so this is everything from making queries simply execute faster from a latency point of view, because just like a database, you can make that query planner smarter and smarter so that you can shave more and more milliseconds off the execution time of a query, as well as you can make the queries execute more efficiently just in terms of the number of CPU seconds that are used at scale, which matters when you are running a top 10 e-commerce site or top 10 media site on the graph. So that's in the query execution bucket. There's also a lot around supporting more and more complex graphs because people are, as you go from just a couple types maintained by just a couple teams to thousands of types maintained by many, many teams about how you use interfaces and polymorphism, like how you account for shared ownership of some of those types, how you provide information that allows some of those types to join data more efficiently in the router. So we're investing in all the things that you need to

build more and more complex graphs in real world cases at massive scale. When many, many teams are collaborating in a very complex business. And this is like the maturation of object oriented programming. Like we're seeing exactly what people need in order to build these very complex graphs. There's also a lot that we can do to make the graph router execute queries more efficiently, like improving technology like normalized partial query caching in the router so that more and more you can execute these queries very efficiently with more sophisticated caching algorithms. So that's all in the router bucket that you mentioned.

But there's also a lot that's around security, access control, policy. Now that people have these graphs, one of the things that they want to do is they want to share them with their partners. So how can we make it so that if you have a partner or somebody outside your organization that wants to use your graph, can we make it very easy to just subset that graph? So you can share just a part of that graph with particular users. Can you centralize your access control? So you kind of have some defense in depth. So you can make sure that particular data never leaves Europe, or certain people only have access to certain fields in the graph, regardless of what the backend logic says. So you have a central policy that you can enforce consistently. Or can we make sure we know exactly who looked at a particular medical record? So many things are possible with declarative security and

access control policies that you can put in this graph router layer. And the other thing we'll be continuing to invest in is subscriptions, how you monitor real-time events on the graph, not just a request-response paradigm, which many people are very interested in. And of course, it's very close to my heart going back to Meteor, which really put real-time front and center. So it's all about the things people need to build more and more complex apps. At the same time, we're going to continue to invest in everything that makes the graph really easy to adopt and get started with. Make Federation easier and easier to use earlier in the development process. Continue to build tooling like Apollo Explorer, which gives you great ways to navigate

and view and query your graph. We just shipped Sandbox, which is a great way that you can use Explorer from the first minutes of your development process, which is, according to our user research, much preferable over graphical or GraphQL Playground or some of these other not-so-maintained open-source tools. It's a totally comprehensive way to browse and query your graph. And we're going to continue to invest in

Apollo Client across all platforms. Especially, we're going to continue to improve the mobile experience. There's more and more use of the graph from mobile devices. We want to meet this particular uses of particular use cases and ways of thinking that mobile developers have and make that be just as great and comprehensive an experience on mobile as it is for JavaScript on the web. And another key thing is the connectors. So we want to make great first-class federated GraphQL execution support across every backend you can think of, every database you can think of, every language you can think of. So between the work we're doing on Apollo Server and the work we're doing in making sure there's great federation support for every language that you would use, that's another thing that I think you'll see a lot of. But really, it all comes back to our users. We believe that the graph is a fundamental new layer of the stack,

that it's going to be as important as the cloud is. It's going to be a change that's just as big as the move to the cloud because when we are able to empower our product engineers with access to all these services, frictionless access, so they can just query it. There's so much more that they can do. And there's so much more that you can deliver. So we think that this is just the beginning

of what's going to happen with the graph being a layer that's as important in everybody's stack as like the cloud is. Well, just an add on question, because well, you sort of triggered me with the last part of your answer. So do you think that there is some sort, do you see it happening, some sort of convergence between this the graph layer that sits on top of APIs that you manage at the moment and data

catalogs? Because if companies are really API centric and their entire functionality is served through the graph well there comes a point I guess well people really need to know what's where and you know they need to have an overview of their of their schemas and so on so in my opinion that sort of overlaps with the kind of functionality that data catalogs offer so do you get that sort of request from your users? Yeah, I think it's a really interesting question because my question would be, who should be building a data catalog in a company? And the conventional answer is probably the data science team.

They're the people that work with data all the time, or at least they're the primary consumer regardless of how it's built. But we have a different point of view, which is that we need to think about not just the data that's available in the enterprise or in any business, any organization, but all the services as well. But it's not really about data. It's really more broadly about services. Accessing data is one service I can provide about the data. But this isn't the offline batch processed world we used to live in. This is a world where all the stuff is constantly changing and it's all constantly in flight and things are constantly happening. So we should think about the services, not just the data.

And when we look at it through that lens, who's best positioned in the organization or who do we most need to serve with our catalog? I would say it's the product engineers because the product engineers are the people who take everything that we build in the organization or who do we most need to serve with our catalog? I would say it's the product engineers because the product engineers are the people who take everything that we build in the cloud and we make it useful to people by building apps that really affect people in their lives. And it's really the product engineers, I would say, that most know the way that we should structure our service catalog. Because if you think about it, back-end engineers, service engineers, they think about, hey, how do I deliver my service

in the best possible way? And it's, but we go through this whole process to understand what makes this stuff useful. You know, the product managers, you know, build a strategy. They work with the UX designers. We get this whole vision

of what the user experience should be. The incredible thing about the graph layer on top of APIs is it's based on the needs of product engineers every day about how to build the products. So it's the output of this whole process to really understand what our users' needs are, the right way to access all the things in the cloud. So a service catalog that's built around the needs of product engineers ends up being, from my point of view, the best place in the business we have to understand what our business domain objects really are. So we think this is going to run on parallel tracks for a while because the needs of your big data style data catalog are a little different from the needs

of a product engineer. But we think that the importance and centrality of this service catalog that's built around the needs of how you use all your services, as evidenced by what the product engineers need to do every day, I think that's going to everybody knows how to use, just like everybody knows how to use a web browser. And it's going to be tied to something that looks a lot like a graph schema registry, like I described earlier, because that provides really the end user view or the human view of what all the services in the cloud are, how we can consume it. And I think, yeah, this will absolutely integrate with some of the data catalog functionality we have today, I think that'll be part of a larger question about how we take all the big data technology and map that seamlessly into the graph. But I think that fundamentally, there'll be a set of technologies that are used on the backend, like you're going to use something like gRPC or thrift or, you know, different types of service mesh architectures or different types of event

buses to coordinate your backend services. That's on one side of the abstraction barrier. The users are on the other side of the abstraction barrier from that. The users don't want to know about the details of how all the services are actually implemented. They want to have a view of their business objects or the objects that matter to people. So that's where I think the graph is really going. It's about how do you take all that back and stuff and ultimately make it useful to people, which is why it's such an important and central

layer of the stack. So will those two catalogs converge or will the graph have one layer, like one catalog that's like more of a human-centric abstract point of view and the data catalogs in the back and we'll have more of a lower level implementation point of view. I think we'll see how that evolves over the future yeah yeah i think that's going to

be interesting to watch and well perhaps to tie that all back into how we started the conversation maybe that's going to be the point of convergence between what you do and what solutions like graph databases and knowledge graphs offer because they're, you know, they have a pretty good track history of managing schema and data catalogs and so on. So maybe that's one point of convergence. Well, anyway, thanks a lot for your time and congratulations again for the funding round and well, good luck with everything going forward. Thanks. It's a huge milestone for us, but more importantly, it's a huge milestone for the community. We're here to serve.

We want to help app developers help the world because we believe in the power of technology and we believe it needs to be in more people's hands. And I really believe that adding this graph layer to the stack is going to unlock so much potential of all the incredible work we've done on the backend in databases and servers and operating systems and the internet.

The question that faces all of us now is how do we make that really useful to people? And by adding this graph layer to the stack that abstracts all that underlying technical detail, so it's super easy for people to use this and build on top of it, make it really useful to them in their lives. We're super excited that we get a chance to

play a tiny little piece of that and that we are super excited that we have the funding to support the community with very high levels of investment in all that technology for many years to come. I hope you enjoyed the podcast. If you like my work, you can follow Linked Data Orchestration on Twitter, LinkedIn, and Facebook.