What term should we use for a federated gateway / router in this specification?

[martijnwalraven]

The draft specification in this repository currently refers to a gateway configuration for what we call a supergraph schema at Apollo. That opens up the question of how we should refer to the component that is responsible for executing federated queries.

At Apollo, we've started referring to this component as a graph router because we feel that better reflects the fact that it intelligently routes requests to appropriate subgraph servers as needed. But perhaps what is needed here is a more neutral term that describes its role within the architecture.

[michaelstaib]

I have thought about this a bit and it would be great to align with the graphql spec ... which does not mention any of this... rather it talks about an execution/executor.

To execute a request, the executor must have a parsed Document and a selected....

So we could call it a distributed executor/composite executor/federated executor.... something in that line.

[martijnwalraven]

So we could call it a distributed executor/composite executor/federated executor.... something in that line.

Yeah, something along those lines makes sense to me.

[benjie]

My issue with "router" is that routers typically just forward whole packets without looking into the payload, only the headers. They don't tend to split things up and distribute them to different locations.

A router is a networking device that forwards data packets between computer networks.
[...]
A router typically does not look into the packet payload, but only at the layer-3 addresses to make a forwarding decision, plus optionally other information in the header for hints on, for example, quality of service (QoS). For pure IP forwarding, a router is designed to minimize the state information associated with individual packets. Once a packet is forwarded, the router does not retain any historical information about the packet.
-- https://en.wikipedia.org/wiki/Router_(computing)

My issue with "executor" is that the term suggests that this is where the backend logic execution happens, but really all we're doing is splitting up the request, delegating it, and then stitching it back together again.

An executor is someone who is responsible for executing, or following through on, an assigned task or duty.
-- https://en.wikipedia.org/wiki/Executor

The term that feels most right to me currently is "dispatcher":

A dispatcher is a communications worker who receives and transmits information to coordinate operations of other personnel and vehicles carrying out a service.
-- https://en.wikipedia.org/wiki/Dispatcher

Essentially, it's in charge of digesting the incoming request and figuring out which services are best placed to execute each part of the request, forwarding those on (delegating), and then reporting on/compiling the result.

[michaelstaib]

Dispatcher sounds more like a messaging system.

My thinking at the moment is that we are describing an alternate executor for GraphQL that gets is execution instructions from the composite schema. But I get where you are going at. In general an implementation of this is more doing the execution planing and then delegates the execution... basically plan -> dispatch -> merge.

[michaelstaib]

Orchestrator?

But then again if you think about it its really a more specialized version of what the graphql core spec describes under execution.

[benjie]

"Coordinator"?

[smyrick]

Quite relevant, I just made this comment on the other issue discussing what we call the schemas, where is this issues is asking what should we call the servers services

tl;dr What about supergraph service and supergraph schema with subgraph service and subgraph schema?

#11 (comment)

[smyrick]

We did a brainstorm on the meeting on Feb 15 and came up with some more terms

• Distributed executor
• Supergraph resolver
• Composer (probably not good)
• Director (from composer making music)
• Conductor
• GraphQL API Gateway
• Coordinator

[JohnStarich]

My takes:

• Orchestrator - Interesting, a tad non-specific though. Not a bad option in my opinion.
• Coordinator - I like this. It's a little closer to a role description.
• Distributed executor – I like this one, it fully describes the role. The downside is its a bit verbose. "Execution distributor" might be slightly closer.
• Supergraph resolver / Resolver – This one's interesting. It borrows a term from the GraphQL spec to describe turning requests into responses, only now it's at a service rather than field level.
• Composer – Consensus was this name is already shared with other terms in the spec. It's also doing more than composition, since it is breaking up requests and sending them off to be executed.
• Director – This one is a bit clearer about its behavior. Director is a general term used to describe management of others, but usually to fulfill a shared goal.
• Conductor – Similar to Director, though possibly more metaphor-like, which may be undesirable.
• GraphQL API Gateway / Gateway – This has some precedence, and it's also a borrowed term from elsewhere like an "ingress gateway". I like this because it describes an entrypoint to a larger system. The only thing is it doesn't describe its behavior in the name.

Of these, my favorites in order are Director, Gateway, Conductor.

[benjie]

I still like "dispatcher" - did you discuss that today? I don't see it among those listed.

"Execution distributor" is also an interesting term; it splits up the execution and distributes it to the source schemas... I like it. Other than verbosity, I like it quite a lot - nice one 👍

I think we should avoid "resolver" in order to avoid confusion with GraphQL field resolvers.

Director and conductor are okay, I quite like them, but they generally are "self driven" (there's not really an "input", though arguably the piece of music itself is the input for a conductor) whereas a dispatcher performs a similar role but is driven by external input (request comes in, dispatcher splits it up and delegates it to the relevant parties and reports back).

[JohnStarich]

Ah, we must’ve missed Dispatcher. That’s a good one, I like it.

[PascalSenn]

There are similar concepts in other areas of CS, i'll just add the following to the discussion to think about:

Coordinator - Distributed Transactions:
In distributed transactions there is a component called the coordinator that coordinates the transactions between different systems and manages the state of the transaction.
I am not sure if the coordinator from distributed transactions is a good analogy in this case, as the two and three phase commits are really a fundamentally different concept with different communication patterns.

Orechstrator - Saga Pattern
In the saga pattern, specifically in the Orchestration saga, there is a component called the orchestrator.
Looking at sagas i see a lot of similarities. On the start of the execution a saga has a predefined flow/statemachine. The orchestrator executes this saga based on this plan. Usually this plan is hardcoded in the saga pattern, but in our case i guess it's the compose that create the plan that then is executed by the orechstrator.

(Query) Executor * - DBMS
In Database system a incoming query is compiled into an execution plan that is the handed over to the Query Executor that executes the request.
If we specify execution in this spec too, and we have an "execution plan" then maybe we should also hand over the "execution plan" to an "executor"

(Query) Processor * - DBMS
Again, a reference to Database systems. The problem with both orchestrator / executor (at least in the previously defined context) is that they both require a definition (plan) of what they have to orchestrate or execute. In the databases theres is a component called the "Query Processor". In Encyclopedia of Database Systems it's defined as

The query processor in a database management system receives as input a query request in the form of SQL text, parses it, generates an execution plan, and completes the processing by executing the plan and returning the results to the client.

*: Query is definitely wrong in our context, hence the brackets

[andimarek]

I use the term distributed engine for the gateway core in Atlassian.

Because fundamentally it is fully spec conform engine, which does its job by distributing the execution.

[michaelstaib]

Thats why I though to call it distributed executor as we talk about the executor in the core spec.