How to best use graphql-mesh and graphql-hive/gateway plus graphql-hive schema registry

[PlayAnyData]

Dear community,

we have the following situation:

• We use the code based approach for the hive-gateway
• Several teams are developing subgraphs independently, which should be stitched together into our supergraph.
• The supergraph is currently composed via graphql-mesh of .gql files in a CI/CD pipeline based on the checked-in gql files of the projects.
• We use the extensions as defined in: https://the-guild.dev/graphql/mesh/v1/schema-extensions which should allow to do additionalTypeDefs.
• Building the supergraph includes hiding queries from the subgraphs as well as extending with additional fields in certain types, which are then programmatically resolved (https://the-guild.dev/graphql/hive/docs/api-reference/gateway-config#additionalresolvers).

Now, we want to enable the following:

• Teams should be able to individually update their definitions without the need to check their generated gql files into a separate repository, where graphql-mesh is building the supergraph. Instead, they might trigger a pipeline (or something else) where graphql-mesh is involved to build the supergraph and deploy the updated supergraph schema in hive schema registry.
• The (deployed) supergraph (hive gateway) should update itself automatically based on the supergraph schema deployed in hive schema registry.

My findings so far are:

• The only way to use hive schema registry with hive gateway is when you have a federation project (as otherwise no supergraph schema is available in hive schema registry, which is what the supergraph hive endpoint is expecting (https://the-guild.dev/graphql/hive/docs/gateway#configuration-file)
• When using federation, we have to upload the subgraph schemas to the federation project individually, where they are composed into one schema.
• The schema can be self composed using External Composition: https://the-guild.dev/graphql/hive/docs/schema-registry/external-schema-composition, for which we would need to create a separate server, which is stitching together all subgraph schemas.
• Using the base schema extension with federation, as e.g. shown here: https://the-guild.dev/graphql/mesh/v1/schema-extensions#schema-registry--hive I was not sure, if I was doing it appropriately, because the resulting schema did not show my schema extensions nor was there any error.
• Even if the above mentioned base schema extension is successful, I think they have to be managed manually and cannot be managed via CI/CD, correct?

What is the most appropriate way of achieving our goal?

Thanks a lot in advance.

[PlayAnyData]

What we ended up with, is the following:

• We have dropped graphql-mesh in favour of federation in hive console.
• Therefore, our subgraphs now publish federation compatible schemas, which also add @inaccessible directives to queries we want to hide.
• Our additional type defs are part of the resolvers, now via @FieldResolver. We overwrite them in the gateway, though, such that the implementation is based on these.

Now, teams can simply update their schema and their urls, whenever they like.