Apollo Federation

Since the graphql schema stitching way is deprecated in Apollo, we are limited to the functionality of Apollo Server.

We really need the support of the Apollo Federation in Hasura.

You guys are promoting the Hasura with advice to use it as a gateway and connect other microservices with a business logic via remote schemas feature, but we want to use graphql-engine only as microservice behind Apollo Gateway in our project. We need most features of Apollo, like tracing, performance metrics, error tracking, safe listing (whitelisting), caching, schema directives, file uploads, custom event-driven subscriptions, automatic persisted queries, vscode plugin

I know about the “allow list” feature in graphql-engine, but it is not useful in real life, because you need something like Apollo Operation Registry. Our CI pushes the operations list to the registry every time when we deploying a new version of our web application on react and apollo client. It is a very convenient way because Apollo has tooling for CI with the ability to check schema changes before pushing these changes to production.

Unfortunately, in the GraphQL community, we become third-class citizens.

So, can Hasura offer at least a small part of features Apollo? We made sure that no.

[kylerjensen]

For us, it would be really valuable if Hasura would conform to the federation spec out-of-the-box. The whole reason for our using Hasura is to save time and eliminate the amount of redundant code we have to write. Having to integrate graphql-transform-federation isn’t very straightforward because we have to define all the keys. Hasura already has all the information needed to conform the spec because it has a list of all the primary and foreign keys.

[carlosbaraza]

This is really important to us as well. Using Hasura as a service should be a fairly simple thing to do.