Consider adding ability to serve _**multiple**_ federated graphs per router instance

[andrew-kolesnikov]

Some organizations maintain multiple separate federated graphs that will be served via router.
These graphs can also be managed through Apollo studio, but deployed independently.

We too would like the ability to serve multiple federated graphs per router instance, which means router has to support multiple supergraph configs, each corresponding to a url pattern:
/public/graphql -> config for graph1 -> schema1
/admin/graphql -> config for graph2 -> schema2

Undesirable alternative would be to deploy several pools of router instances, each serving its own supergraph

[abernix]

Thanks for bringing this up!

The suggestion today is still to run multiple router instances, each serving their own supergraph. We completely understand this is not the ideal case, but it's important that we make sure that multi-tenancy supergraphs are really durable/safe/stable before running quickly in that direction — your example of mixing admin and public in the same instance is very good example of why it's important that we be thoughtful and carefully analyze the impact. We also want to make sure that we're thoughtful about the observability of that, and a number of other important considerations.

With that in mind, we do have #31 open which captures the spirit of this, even if the approach for negotiating which supergraph might take on forms other than path-based solutions (though that is certainly one way to negotiate the graph!).

Feel free to subscribe or upvote that issue, but please note that it's not on our near-term roadmap — which includes a lot more adoptability and customization things which have a higher priority.

Thanks again!