AWS Federation support via AppSync Merged Query

AWS recently published an RFC around its planned Merged Query capabilities into AppSync, AWS’s managed GraphQL product offering. The introduction of Merged Query looks to address the requirements around query federation, a feature that’s been available in the Apollo GraphQL product, which until now, AWS has been directing customers towards who had a need for graph federation support. 

GraphQL federation enables a decentralized development model which allows teams to manage their individual GraphQL schemas, resolvers, and endpoints (sub-graphs) and publish them to a central super-graph. This enables consuming applications to streamline their data access patterns which today may span multiple connections down to a single GraphQL query. For more on the graph federation topic, you can read how Netflix had architected its GraphQL capabilities here.

With Merged Query, AWS attempts to differentiate itself from the Apollo Federation implementation, which relies on a central gateway GraphQL schema which acts as a router to the underlying sub-graphs. For more detailed information, read the Apollo approach documentation.

This approach introduces an additional network hop at the gateway layer to resolve incoming queries to their underlying sub-graphs. AppSync’s merged query approach is novel in that it relies on a build time composition where all registered schema are merged into a new single schema (a supergraph) with direct connectivity to the underlying data sources eliminating the need for a gateway schema resulting in reduced latencies along with support for real-time subscriptions to changes in underlying source systems.

Historically, adopting a build time composition approach implied that each subgraph was responsible for implementing a complex deployment pipeline to ensure their schema’s were merged into the supergraph. The AppSync Merged API capability provides teams upstream to independently manage their AppSync schema’s and resolvers (source API’s or subgraphs) and have changes automatically published to the merged API or perform the merge on demand. According to AWS, teams can leverage the AWS console, the CLI or SDK to build a “Merge” button to orchestrate this merge process. How that’s actually done will be a topic for a potential follow-up post. 

Supporting directives for resolving conflict

AppSync’s Merged API supports directives to resolve field and type conflicts between source API’s when those source API’s are merged. These directives include: 

@canonical allows resources with this directive to take priority in a merged schema when multiple source API’s share the same GraphQL type or field. 

@hidden allows source API’s to exclude types and fields from being merged into the merged API. Access to these resources would only be available via the Source API.

@renamed allows fields and types to be renamed during the merge operation in cases where the same type or field name needs to be accessible from multiple source API upon merge.

When no derivatives are specified for a conflicting type, AppSync publishes a fully merged type which is a union of all of the fields from the source definitions of that type. Examples of how this works in practice can be found in the original GitHub RFC.

A Merged API is created by an owner who can issue an invitation to downstream Source API’s to publish or merge their schemas & resolvers. Source API’s are responsible for configuring the appropriate IAM roles and permissions. Once properly configured, Source API’s accept the invitation by triggering an initial merge. This is a unidirectional relationship between the Merged API and the downstream source API’s. Source API’s have no access to modify the Merged API directly. Merged API supports breaking change detection and will return an error back to the source API indicating a problem with the merge attempt.

The Merged API approach does address some of the latency concerns introduced with the Runtime Query Composition approach. However, it does so by potentially introducing additional complexity into your CICD process. While AWS’s attempts to streamline that process with the auto merge capability, how efficient that process actually is and whether the latency gains are worth it become an organizational decision. 

Furthermore, Merged API works only with AppSync Source API’s which may be a problem for larger enterprises that may already have different flavors of GraphQL deployed in their organization or are apprehensive about vendor lock in. AWS does recognize this as a limitation and seems open to supporting different flavors of GraphQL in their roadmap. Additionally, some organizations may have corporate policies that may block direct access to data sources across accounts. This may make it difficult to adopt an AppSync strategy internally. 

AWS AppSync does warrant a closer look for teams looking to introduce GraphQL and who do not have concerns about AWS lock in. The AWS managed service capabilities are very attractive in terms of reducing operational overhead and provide a frictionless enterpoint to get started. Your organization will need to determine whether the current pricing model of $4.00 per million queries/operations provides value.