The folks at Apollo have been working with GraphQL since 2016, back when they were still Meteor Software. Versatility has always been at the core of Apollo, when they released their GraphQL-based datastack in 2016 its calling card was ‘any backend, any language, any client’. The idea was clear, to have one tool for building a GraphQL client and server which can then be used to either build a new app from scratch or fit into an existing project, so that it can take full advantage of the perks of GraphQL.

Apollo Server and Apollo Client

At the core of the stack were Apollo Server and Apollo Client and both became popular tools in the community in their own right. Apollo Server ran as a GraphQL translation layer on top of the existing backend and Apollo Client was a Relay-like client that could be adopted in any application. The same flexible approach was clearly apparent in both. Apollo Server works with a wide range of different data sources via open-source implementations (HTTP/REST APIs, SQL databases, MongoDb and others) and Apollo Client is view-layer agnostic and works with a number of frameworks like React, Angular, Vue or even vanilla JS.

The Supergraph

The versatile approach, started with those two tools, has now produced a new stack called Apollo Supergraph. It's a single solution for bringing together data from a wide variety of sources into a single Supergraph, a unified layer made from modules interacting with each other. Apollo has always worked according to their principled GraphQL approach, inspired by the Twelve-Factor App methodology. It's easy to see here as well as the entire Supergraph concept is based around three core principles:

• a unified composition layer: Supergraph is meant to be a graph of graphs, connecting all of the company’s data, microservices and digital capabilities into a new unified composition layer.
• modular architecture: Supergraph’s modular and declarative architecture lets teams quickly integrate modular data, services and business logic into that unified layer.
• agile approach: Taking a bottom-up instead of a top-down approach makes for faster and more involved development. Every dev and team is encouraged to publish changes into the schema on their end, and the actual use of schema is what pushes development forward, by having everyone focus on decisions and improvement.

Three building blocks

So everything is about making a unified layer by using modules and focusing on constant improvement. While that gives us some indication of what were the main ideas behind creating the stack, we still need some more specific information to get the full picture. Similarly to the three principles the Supergraph also has three core components:

• Apollo Federation is what is actually responsible for building the Supergraph, by composing a number of subgraphs (GraphQL services) into a supergraph. Following the modular principle each subgraph is an independent self-contained component with its own schema, which can be worked on and deployed individually. Subgraphs can be written in 20 different programming languages so the bottom-up, flexible approach is also evident here.
• Apollo Router is what is responsible for running the Supergraph. The runtime is a successor to the previously used Apollo Gateway: it boasts 10x lower latency, 10x higher throughput and 12x lower variance compared to its JavaScript predecessor.
• Apollo Studio is what delivers the Supergraph. Validation, automation, observability, all that good stuff you need to make delivering changes quickly and safely possible. It's even more true in the rapidly evolving environment of the Supergraph where devs and teams are encouraged to work on each other's contributions. Schema Checks and Launches automatically validate the schema in development, which helps prevent breaking changes before they occur and makes past and ongoing changes easily visible.

Spread the word

I think it's safe to say Supergraph aims very high. It wants to be a true enterprise stack that you can adopt and work on company-wide regardless of what languages the programmers use and what types of services and data sources need to be integrated. If the hype is real it can really become a catch all solution that will streamline work and make full use of the advantages of GraphQL along the way. The Apollo team has been very reliable so far so if you’re a GraphQL enthusiast it's definitely something you want to keep an eye on and tell others about. After all wide adoption is key if we ever want to start working together using the Supergraph.

A guest blog post for GraphQL Editor blog by Michał Tyszkiewicz

Speed up your GraphQL API development

GraphQL Editor is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster. Try GraphQL Editor for free!