Accelerate your Apollo GraphQL federation journey with Hasura

When talking to developers evaluating Hasura and Apollo GraphQL, we often discuss how these two popular tools complement each other and where they diverge in their use cases. While both technologies coexist in the GraphQL ecosystem, the path from data to a production-grade GraphQL API involves different approaches when using Hasura versus Apollo.

In this blog, we will present an architecture in which Hasura and Apollo can work together effectively, especially with Apollo federation tooling. We will outline the specific situations where Hasura shines in developing and managing production-ready GraphQL subgraphs at scale, and how it can accelerate the GraphQL federation journey with Apollo, particularly within enterprise environments.

Hasura is a data API platform that helps you build GraphQL subgraphs on data sources (PostgreSQL, MongoDB, ElasticSearch, Rest/gRPC APIs, etc.). It can also help you create a supergraph, a federated API layer on top of a heterogeneous set of data sources. It automates the creation of scalable, production-grade APIs – an approach called domain-first GraphQL, ensuring high-quality endpoints with built-in security, performance optimization, and real-time capabilities.

In essence:

• Hasura can be used to generate subgraphs on any data source. The subgraph can be used in other federation tools to build a federated GraphQL API.
• Hasura can help you build a supergraph that is highly composable, backed by declarative AuthZ.

We have put together some architectural principles of what an ideal supergraph is at supergraph.io and what are the characteristics of an ideal subgraph is to be able to power your federation journey.

Apollo is a GraphQL tooling company that provides a set of open source and proprietary tools to enable developers to build apps with GraphQL. Apollo Server is the JavaScript implementation for writing a custom GraphQL server. Apollo GraphOS is the platform for building, managing, and scaling a supergraph (a federated graph composed of several subgraphs).

In essence:

• Apollo has tooling (GraphOS / Apollo Router / Apollo Schema Registry) to create and run a federated GraphQL API.
• Apollo has a javascript server library to write a schema first GraphQL server with custom resolvers.

What Apollo doesn't do?

Apollo doesn't have tooling to help you efficiently generate high-quality subgraphs over any data source. Apollo Server gives you the scaffolding to build subgraphs manually using Node.js, by defining a schema and then you are required to write custom GraphQL resolvers – an approach called schema-first GraphQL.

But since Apollo federation also doesn’t impose a constraint on how you build your subgraphs (other than a few proprietary directives), you are free to pick and choose any language/framework or tool (like Hasura) to build your subgraphs, and then federate over them using Apollo.

Learn more about the advantages of domain-first approach over the schema-first approach for building domain APIs in The GraphQL Handbook.

We will go over the specifics of how Hasura can be used as a subgraph in the context of Apollo federation in this post.

Before we dive in, let's do a quick primer on GraphQL federation.

Federation in GraphQL is the ability to declaratively compose multiple GraphQL APIs into one unified, federated graph. A single GraphQL endpoint abstracts away the underlying disparate sources of data and APIs, enabling clients to make a request to fetch any data they want efficiently.

A federated GraphQL API brings about most* of the benefits of a monolith for consumers (single endpoint, joins across any two or more types, etc.) and microservices for producers (better ownership and independent release cycles) of the API.

Typically, in organizations, APIs are built by semi-independent teams with some overlapping functions. The documentation for the APIs may exist, but nothing combines or connects these APIs. They are available independently for consumption. As use cases grow on the consumption side, the need to connect these APIs have risen. GraphQL, with its schema and type system and the query capabilities, makes it a great choice to connect these APIs.

GraphQL federation evolved from schema stitching, which is a naive unification of multiple schemas.

(* GraphQL federation has some inherent drawbacks, which we will talk about in a separate post)

Federation specification and standards

Federation in GraphQL currently does not have a standard specification defined by the GraphQL foundation. There are implementations from Apollo with their Apollo federation v1 and v2 specifications and there was a community contributed attempt with GraphQL Fusion.

There’s active effort in the GraphQL Foundation to standardize the specification for federating GraphQL APIs. Learn more about the Composite Schemas Spec.

Hasura is actively involved in the foundation working group to standardize the specification. Currently, Hasura works as a federation layer for any subgraph source. Hasura also supports Apollo federation spec in the subgraph to make the subgraphs it autogenerated compatible with Apollo federation.

Already using the Apollo federation?

If you are already using Apollo GraphQL, you have several choices to incrementally and gradually bring Hasura into the mix to accelerate your federation / API journey.

The role of subgraphs in GraphQL federation

Any GraphQL federation strategy relies heavily on the quality of the subgraphs involved. Only high-quality, high-performance subgraphs can truly accelerate your GraphQL federation journey, providing the necessary foundation for a scalable and maintainable GraphQL architecture.

To achieve this, subgraphs must:

• Have standardized APIs: API standardization is crucial for defining the structure and relationships of the data. It ensures consistency and predictability across different parts of the graph. Standardization ensures consistent and predictable data structures and operations. It involves separating models (data resources) and commands (business logic methods), and enabling filtering, sorting, pagination, and aggregations on models.
• Offer composability: Subgraphs should be designed to be easily composable, allowing them to be reused and integrated seamlessly with other subgraphs. Composability attributes enhance the API's usability by allowing complex data operations such as joining related data, nested filtering, sorting, pagination, and aggregations. These capabilities reduce the need for manual API aggregation, promoting a self-serve API consumption model.
• Be highly performant: Performance is tricky in GraphQL subgraphs. Subgraphs must handle queries efficiently, minimizing latency and maximizing throughput. Learn more about how to design high performance GraphQL subgraphs – Compile, don't resolve: Designing a feature-rich, high-performance, domain-driven GraphQL API.

As a powerful and flexible GraphQL engine, Hasura subgraphs fit well with the Apollo federation strategy by providing high-quality and high-performance subgraphs out of the box.

Panelists Jeff Auriemma and Shane Myrick from Apollo GraphQL and Uri Goldshtein from The Guild had this to say in a webinar on accelerating GraphQL federation by accelerating subgraph delivery:

“You want your tooling to help you integrate your existing domains as quickly as possible… you can take any database, use Hasura, and you have a subgraph easily.”

Let's look at some of the architectures where you can use Hasura and Apollo together.

Apollo federating over GraphQL subgraphs, some of which are built using Hasura

If you are using Apollo GraphOS for GraphQL federation, you can feed a Hasura-powered GraphQL endpoint as a subgraph into your Apollo supergraph. Hasura will let you build new subgraphs much faster than building them by hand with Apollo or other DIY methods. You can also gradually port existing subgraphs to Hasura if the maintenance burden of those is getting cumbersome.

Hasura can also help federate over GraphQL subgraphs, including those of the Node.js powered Apollo Server subgraphs. Learn more about how Hasura can be used as a federated gateway.

Hasura can be added as a subgraph in a supergraph powered by the Apollo federation. Here’s how you can do it:

• Create a Hasura DDN project with an API on top of a datasource.
• Enable Apollo federation fields in Hasura DDN metadata.
• Marking a type as an Apollo Entity.

Check out the docs for more details about the Hasura DDN subgraph <> Apollo federation integration.

GraphQL practitioners who leverage domain-first approaches see significantly higher return on investment (ROI) for their efforts/spend: approximately ~10X vs. 1.5x with schema-first methods.

For a detailed writeup on a model to benchmark value from GraphQL and a study in contrast form these two approaches, please check out this post – Measuring Impact: A guide to the ROI on GraphQL.

In the context of GraphQL federation, leveraging high-quality subgraphs is essential for creating scalable and maintainable GraphQL architectures. Building these subgraphs can be a challenging and time-consuming task, particularly when it involves defining schemas and writing custom resolvers manually. However, integrating tools like Hasura and Apollo can significantly streamline this process and enhance the overall performance of your GraphQL APIs.

By combining the strengths of Hasura and Apollo, developers can achieve an efficient and high-performance GraphQL federation setup. Hasura can generate subgraphs that seamlessly integrate with Apollo's federation tools, providing a robust foundation for a unified federated graph.