Tracing back the origins of the Apollo GraphQL platform from an insider’s view to uncover a broader perspective on what’s to come.

Last week, Apollo GraphQL announced the supergraph—a declarative, modular, and agile approach to architecting the graph. An evolution of the federated graph, the supergraph has now become available to anyone thanks to 3 major updates to the Apollo GraphQL stack:

1. Last month saw the release of Apollo Federation 2, a tool facilitating the creation of a unified supergraph combining multiple GraphQL APIs.
2. The Apollo Router supergraph runtime has been made generally available.
3. The Apollo Studio, a cloud platform to help build, validate, and secure graphs has been updated to include the Schema Checks and Launches functionalities for free.

Why is all of this such a big deal? In order to get the full picture, let’s first take a step back to trace how these tools came about.

Making data distributed

Before Apollo, there was Meteor, a free and open-source isomorphic JavaScript web framework based on Node.js. Originally released in 2012, Meteor was founded by the same guys who later founded Apollo, that is Geoff Schmidt, Nick Martin, and Matt DeBergalis.

These three founders along with their team did a really great job with Meteor. Ahead of its time, it allowed for rapid prototyping and produced cross-platform code with ease. Developers loved it. The Meteor team was very good at building communities and the framework was genuinely community-driven (which, on a side note, is something that they definitely carried over to Apollo GraphQL).

However, arguably the greatest innovation of Meteor was its Distributed Data Protocol, or DDP. It does exactly what it says on the tin. It's a client-server protocol that queries and updates a server-side database. It also synchronizes these updates among clients. Hence, clients and servers everywhere can have the same set of data that can be accessed very quickly because it's distributed. Further, the publish–subscribe pattern that DDP uses automatically propagates data changes to clients without the need for any extra synchronization code.

From Meteor to Apollo

Back in 2012 the DDP approach was really novel and groundbreaking. Then in 2015 Facebook open-sourced GraphQL. I remember it caused quite a stir in the Meteor community since GraphQL and DDP were sort of competing technologies. Now, what I believe happened around then was Geoff, Nick, Matt, and team were like “Wow, GraphQL is great. But we can make it even better.”

And they did. They took all their expertise in distributed data coming from Meteor to create Apollo GraphQL. The data expertise aside, they also carried over something else from Meteor, which was the developer experience it provided. Meteor took away a lot of mundane work from developers, making things easier for them, and I believe the same thing was a top priority for Apollo from day one.

Forging the enterprise-grade gold standard

Along the road, a great innovation took place. Having started working with enterprises such as Airbnb and Audi, Apollo faced the challenge of handling the complexity of numerous APIs requiring multiple graphs. Working with Audi at the time, me and my company Xolvio were involved in creating one of the first ever, large-scale, distributed GraphQL implementations. We worked very closely with the Apollo team and that was one of the projects that helped shape what later came to be known as Apollo Federation.

The Apollo Federation solved the problem of schema stitching, allowing many separate graphs to coexist while making up a larger, federated graph. In my view, this was the point when Apollo ended up really leading the GraphQL charge. With Federation they introduced the subgraph/supergraph specification to the general GraphQL spec, truly improving upon Facebook’s original concept.

These were the beginnings of the supergraph, which thanks to Apollo’s smart tooling soon became the enterprise-grade gold standard for GraphQL and provided the missing ingredient to shape this technology's future.

Moving beyond the enterprise

Fast forward to 2022, Apollo’s tooling is being used by 30% of the Fortune 500. With the involvement of early enterprise adopters such as PayPal or Netflix, the Apollo platform matured through the experience gained in these high-scale projects over numerous use cases.

The recent product releases that I listed at the start of this post constitute a crowning moment in the development of the Apollo platform. I see the progression of these tools as stepping stones towards the creation of the supergraph.

However, the real reason why I think the supergraph announcement is pivotal is because the Apollo team has opened up the supergraph to everyone. Apollo Studio was originally developed to help enterprises productionalize Federation, but now the state-of-the-art SaaS tooling for creating and operating supergraphs is generally available in the free tier and team packages.

Because of this, the barriers to company-wide GraphQL adoption have never been lower. Using these fantastic free tools developers can swiftly bring their first graph into production and realize its value in their organizations. The supergraph architecture allows them to work independently while reaping the great benefits of a unified graph.

A recent DZone survey on enterprise application integration reported higher than expected prevalence numbers for GraphQL as an API architecture. According to Gartner, more than 50% of enterprises will use GraphQL in production by 2025. Considering its wide availability and developers’ love for Apollo’s tooling, I dare say the real adoption rate may possibly surpass that prediction. Regardless of actual numbers, I’m sure the supergraph is going to greatly contribute to sky-rocketing GraphQL adoption well beyond the enterprise in the next few years.

Peeking beyond the horizon

I strongly believe the Apollo platform is already a vital part of the modern development stack. With its wider availability I expect more innovation to take place, which makes me incredibly excited about the possibilities that await in a future global GraphQL environment.

As more and more organizations adhere to the supergraph specification, I foresee tooling coming along to amplify the interoperability of APIs spanning across multiple companies to create value in ways we have not seen before.

Apollo CEO, Geoff Schmidt, said last week he thinks the supergraph is something that history will look at as being as big a deal as maybe even the cloud itself. I’m positive we’re witnessing history being made and I believe GraphQL’s future impact may well surpass current perceptions and expectations.

The supergraph is just the beginning and the mark of a new era of distributed data. Given the Apollo’s founders’ history with the Distributed Data Protocol and their proven ability to create the GraphQL standard, I can see how they’re going to take us to the moon and beyond. 🚀