search

graphql-kit / graphql-voyager

🛰️ Represent any GraphQL API as an interactive graph
https://graphql-kit.com/graphql-voyager/
MIT License
7.81k stars 516 forks source link

FR: Federation and/or multiple graphs/subgraphs #245

Open hinogi opened 2 years ago

hinogi commented 2 years ago

Are there any plans to add support for working with multiple graphs in the sense of Graphql Federation with distributed graphs where you can see where the dependencies jump to a different graph? It might be over complicated but usually there is some kind of SDL hint on what graph to jump to.

LunaticMuch commented 2 years ago

That's an interesting point, but not sure how it could be done.

From the top of my mind, if you query the gateway, it won't let you know about subgraph and this is intended. You could potentially query all subgraphs and put together information, but won't be effective I suspect. I feel the only way would be to manually put together all the schema files and follow where the schema is extended, evaluating apollo specific directives. It feels hard.

From a consumer perspective, I am not sure about the value provided, as the consumer actually should be aware of the backend (federated or not, and how it's being federated). From a tooling perspective, it could help but not sure to which extent 🤔

hinogi commented 2 years ago

It is actually more difficult, you have an SDL and an API. You can see that concept in the seldom known apollo workbench. It holds also information about the name of the subgraphs. In the example the LOCATIONS subgraph is shown. So there is a graph with information on what graphs are available and which field in which graph is external and in which not, it is only one hell of AST crawling away ;)

https://www.apollographql.com/docs/federation/v1/workbench/overview#view-supergraph-and-api-schemas

hinogi commented 9 months ago

That's an interesting point, but not sure how it could be done.

From the top of my mind, if you query the gateway, it won't let you know about subgraph and this is intended. You could potentially query all subgraphs and put together information, but won't be effective I suspect. I feel the only way would be to manually put together all the schema files and follow where the schema is extended, evaluating apollo specific directives. It feels hard.

From a consumer perspective, I am not sure about the value provided, as the consumer actually should be aware of the backend (federated or not, and how it's being federated). From a tooling perspective, it could help but not sure to which extent 🤔

I guess you could use https://the-guild.dev/graphql/tools/docs/api/modules/merge_src to merge multiple .graphql files into one before using it into voyager

LunaticMuch commented 9 months ago

I guess you could use https://the-guild.dev/graphql/tools/docs/api/modules/merge_src to merge multiple .graphql files into one before using it into voyager

I depends what you aim or look for. Reading files is ok, but if you then generate an SDL you are gonna be stuck because the SDL will not contain any info. An option is to read the sdl field from each subgraph which. would return the unparsed copy of the sdl. Still, you need to decide what to do with that and how to inject additional info on the UI

hinogi commented 8 months ago

https://github.com/apollographql/supergraph-demo-fed2/blob/main/supergraph/schema/docker.graphql

looking at that example, it really sounds like a nightmare :D