Apollo query level routing

[saravind-hotstar]

We would like to evaluate if there are constructs in the GQL schema of the subgraph to achieve the following

• Route a single query to different deployments based on the request context
• Route a different query to different deployment based on the request context

Let me provide a few concrete examples to enumerate it betterSuppose we have subgraph foo with queries x,y,z and foo can have deployment foo-1, foo-2, foo-3 with symmetric codebases
subgraph foo {
type query {
x(x1, x2...)
y(y1, y2..)
z(z1, z2..)
}}

Conditions

• route x to foo-1 if the request header is the route: 1
• route x to foo-3 if the request header is the route: 3
• route x to foo-1 if no route header is present or the value is empty
• route y to foo-3 only in all cases

As we understand, the schema update to the registry captures the routing URL at a subgraph level, which means the following options were available

• Subgraph foo has to decompose to foo-1, foo-2, and foo-3 with the renaming of queries which semantically may not be right
• Push this logic to load balancers
• Create multiple GQL gateway with one variant associated with one gateway which would lead to duplicate super graphs + deployments of GQL gateway

Please do suggest is there alternatives and better clean solves

[Geal]

as a quick answer, the subgraph plugins can edit the subgraph request URL, so it should be possible to dispatch to different URLs depending on a condition, like a header in the client request.

Separating per fields in Query is harder, because the query planner might send query { x y } to foo-1 because it handles both fields, so here you could separate in logical subgraphs: they have the same code, but you explicitely tell the router that y is handled by a separate one:

enum join__Graph {
  FOO @join__graph(name: "accounts" url: "http://foo.com")
  FOO3 @join__graph(name: "inventory" url: "http://www3.foo.com")
}

type Query {
  x: Value @join__field(graph: FOO)
  y: Value @join__field(graph: FOO3)
}

Then y will always go to foo-3, and you can have the subgraph plugin that recognizes the http://foo.com URL and replaces it according to your balancing configuration. Would that work for you?