Migrating from Apollo Federation

[dobrynin]

Hello!

Firstly, thanks for all the work you guys do making these tools.

We're currently planning our approach to support subscriptions w/ our existing Apollo Federation graph (I'm sure you are all familiar w/ the issues surrounding that). We'd like to define the subscriptions in the same services that currently implement our queries and mutations. My question is, should we stitch the federated gateway w/ the subscription types + resolvers from the individual services, or should we just completely replace the Apollo Gateway w/ a schema stitched gateway? We have ~10 federating services, is it as easy as swapping out the gateway and using @gmac's federation-to-stitching-sdl tool? Or would we have to write lots of custom logic, e.g. individual resolver logic for each of our federated types?

Appreciate any insight you have into this, thank you!

[gmac]

Hi @dobrynin!

Good question. There’s lots of ways you could approach this. The main constraint here is that subscription types need a direct link to the gateway so that we can proxy service > gateway > client. Otherwise, everything else can do what you want.

A naive approach would be to take the Federation gateway as it exists and stitch it together with the subscription types filtered out of their respective subservice schemas. This leaves a lot of what you already have in tact, but is really messy and adds a middle proxy layer of stitching > federation > subservice.

The simpler approach is almost certainly just to pull out the federation gateway and stitch the subservices directly. Then the complete subservice schemas, subscription types and all, are direct members of the gateway schema and less prone to indirection errors and inefficiencies. How you stitch the subservices is up to you. That automatic SDL transformer I wrote is a quick start, although buyer beware that it hasn’t been battle tested against the plethora of possible federation edge cases (please report back on your experiences!)

While the SDL transformer would be a good start, I would recommend eventually phasing out “buildFederatedSchema” tooling one service at a time if you commit to this direction. Stitching doesn’t use all of federation’s ghost field additions (external), so the subservice is needlessly complex as a GraphQL resource. Also, federation makes heavy use of computed field patterns (requires) to do fairly mundane object associations. If you’re phasing out federation anyway, you might as well invert these situations into simpler merged foreign key types that don’t involve passing dependencies between services.

[dobrynin]

Think I was able to answer my own question by referencing your Vox Media blogpost

Type merging encourages sub-service schemas to be independently valid. A type may exist in any number of services, and each service simply defines as many (or as few) fields for the type as it has available. Types with the same name are then merged into one unified type in the gateway schema. The only requirement is that each partial type containing unique fields must register a query for itself with the gateway
...
While you have to write your own service APIs for Stitching, the bare-metal nature of this configuration is quite extensible.

I suppose these new root-level queries are what you meant by "service APIs"?

[gmac]

Keep in mind that there’s no reason that the top-level query can’t be the Federation “_entities” query, which is how that federation-to-stitching-SDL wrapper works. So while migrating, just keep everything as-is running through the federation entities query, and then start splitting merges out to use their own dedicated queries if you want to... or don’t! A federation-style entities query technically works fine, it’s just a lot klunkier passing around typed object keys than it is to pass around primitive scalar keys.

[dobrynin]

Got it! I need to dig deeper into how the _entities query works. Also will need to wrap my head around the @merges directive to achieve federation-like hot-reloading.

Thank you for all the recipes! I think if I can just figure out how to combine a few of them into a bespoke "super-recipe" we should be good to tackle subscriptions.

[gmac]

For understanding the _entities query, see https://github.com/gmac/schema-stitching-handbook/tree/master/federation-services#summary. That provides a fairly illustrative example of how Federation uses it.

[gmac]

As for the merge directive, there’s a good primer on SDL composition here https://m.youtube.com/watch?v=dE9cJsxOLeQ