Apollo GraphQL, a pioneer in the use of open source and commercial GraphQL API technologies, announced today a $130 million Series D funding round led by Insight Partners with participation from existing investors including Andreessen Horowitz, Matrix Partners, and Trinity Ventures. This raises Apollo’s valuation to over $1.5 billion and is empowers it to execute on its vision to “pioneer the Graph as an essential new layer in the tech stack that serves as a unified representation of an organization’s services, data, and digital capabilities”. That sounds grand indeed. We discussed with Apollo CEO and Founder Geoff Schmidt, covering everything from Apollo’s origins to its implementation and future plans.
Product developers and product engineers, silos and integration
Schmidt has a somewhat unconventional background, but that did not stop him from founding Meteor, a free JavaScript-based open-source platform for app development that raised $53 million before being acquired by Tiny for an undisclosed amount. A successful exit did not keep Schmidt away from venturing again. He saw a challenge in Meteor: you could only use it to build new applications. He saw that there was a chance to have a much bigger impact if he could build a version of that technology that would integrate with any back-end, any front-end. Apps used to be comparatively simple, Schmidt noted. You had 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 much more complicated. People are building apps that run all over the place. Monolithic services are now being broken down into granular microservices. Microservice fabric is an architecture that many people have now, and it serves some needs well, but what that’s done is it’s created a lot of complexity, Schmidt noted. The whole point of building all these services in the cloud is so we can build apps, he added. If you’re a product developer, you want your services to be very reusable, modular, independent, so you can combine them in any way you might need in the future. So if you’re looking at the world from a back-end 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 back-end. Schmidt thinks that’s really different from the needs of product engineers. Their job is to go create those experiences that people use every day. And that means they need to combine all of those different things. Originally, Schmidt and his team started building what they thought of as a new version of Meteor, one that would work with any back-end and front-end, at the scale of the world’s largest applications and teams. Then the GraphQL specification was released, and the team realized it was the right query language to use. Of course, GraphQL is just a specification in need of implementation. The aim is to replace point-to-point API integration with something more scalable and streamlined: “One interface, where you have one view of all the data and services, and you can query it and access it just like you to access a database. So what we’re doing is we’re creating this virtual graph layer, and we call it the Graph because it’s connected,” said Schmidt.
From vision to implementation
GraphQL is already top of mind for 86% of JavaScript developers. As for Apollo, it’s currently used by 30% of the Fortune 500, its people said. Apollo leverages an open core model, with part of its offering being open source and part of it belonging to its Enterprise version. So there is traction, and that, alongside Apollo’s grand vision, is what got investors interested as per Schmidt. Apollo’s previous funding round was $22 million, and things have unfolded times ten since then, he added. But how does that grand vision translate to technical architecture and implementation? Apollo sports a GraphQL client called Apollo client. You don’t necessarily need a client to access a GraphQL graph, but there’s much more you can do when you have a smart client in the mix, like cache data, for example, Schmidt noted. The main goal is to use the client to build user interfaces, and it comes in many flavors for different programming languages and environments. Then there is what Schmidt referred to as the graph Router or the equivalent of a database query planner. Apollo does not store data, so the Router just needs to know how to route queries efficiently, but that does not make it less crucial or complicated. “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,” Schmidt said. Then there is Apollo Studio, the heart of which is the Schema registry, as Schmidt put it. Schema is an important part of GraphQL, and Schmidt likened Apollo’s Schema registry to a DNS service, keeping track of types, addresses and access control rules. There are also tools like Apollo Explorer, which lets users point and click to build graphical queries while allowing them to search and navigate graphs. Schmidt emphasized features such as query latency prediction and CI/CD, access rights and security, as well as Federation, an open standard championed by Apollo. But what really is at the heart of Apollo’s architecture is the Router. This is where most of the complexity lies, and as the number of back-end services Apollo connects to grows, so does the complexity and the need to optimize. Schmidt confirmed what Apollo’s VP of Engineering Josh McKenzie hinted at – this is where most of Apollo’s innovation efforts will be focused on.
Data, services, catalogs, schemas, registries, and graphs
Although the differentiation between Apollo and solutions like graph databases, for example, is clear, there are also some points of convergence. The reference to a “unified representation of an organization’s services, data, and digital capabilities” was not lost on us. The point that seems to crystallize this is the schema registry, which in some ways looks like a data catalog for services. The graph layer on top of APIs is based on the needs of product engineers, Schmidt noted. So a service catalog that’s built around the needs of product engineers ends up being the best place in the business. Schmidt said: Schmidt believes that a graph schema registry provides the human view of what all the services in the cloud are and how we can consume them. Eventually, it will integrate with some of the data catalog functionality we have today. Interestingly, a growing part of existing data catalogs is also adopting graph and schema features. This seems like a good match to manage the complexity and the metadata and governance needs that come with it. While graph databases look like a more broadly applicable foundation, and the funding and valuations in what is by now a well-defined and booming category are higher, Schmidt’s point about the importance of services and APIs to organizations is a valid one. The bigger picture here is that whether people take a data-driven or a service-driven point of view, eventually, the need for schema, metadata, and registries becomes evident. The interconnected nature of all the different service endpoints and data points is sinking in too. Graph-shaped and schema-centric solutions are emerging to address those needs.
