What we love about Federation is that it can take a complex supergraph request and distribute the processing of it to relevant subgraphs. It takes one thing, creates multiple, aggregates responses and sends them back (well, it does more than that, but this is relevant for this post).
Now, I’ve dealt with clients (regardless of their “endendess”, front, back, sideways, …) that do not know what they need at build time. They only get to discover this at run time. Some reasons include specific user preferences and configurations, screen/view variations, custom extensions and plugins, etc. Most often I see the following patterns applied:
- Ignore the issue. Let each client’s code piece make individual requests to get what it wants. This effectively yields underfetching at the “use case” level, even with GraphQL - a single click may produce many requests to gather everything that’s needed. Worse, individual responses may duplicate same entities and may yield inconsistent revisions of those or inconsistent sets of entities.
- Try to reduce the issue by caching. This gets tricky with partial data communication, does not address the entity set consistency issue and introduces cache state trust headaches… “Why isn’t my deposit showing up?”. It doesn’t reduce server trips much either as the requests are likely at least a tiny bit different.
A way I fought this issue in the past is to have the mirror image of Federation, or “Federation in reverse” in the past. Full disclosure - this was before GraphQL, so not GraphQL, but using a proprietary tech I made to solve similar problems GraphQL does.
The way it works is that, when any piece on the client knows it needs something, it can leverage the framework to aggregate all the requests from what can be discovered needed from others. Think of it as a discussion:
OP: Hey, I’m about to to display a list of people. I care about their names and emails only, but I’m told to work with you to show extra stuff. What do you need?
X: Oh, please include the country each person lives in.
Y: I need to know the id and the name of the most recent employer of each.
…
Given client-side coordination, what would turn into multiple requests could be aggregated into a single one and sent to the GraphQL API, say Apollo Router, to do its work on it.
As this reduces trips, it not only reduces the underfetching problem but also reduces or eliminates the consistency issues as all the data could be retrieved together. Caching or not, this improves the performance wherre it hurts most - complex cases and does not interfere with the simple cases. The performance gains may reduce or eliminate the need for caching and, thus, with cache-related headaches.
How many of you would find this helpful? Sure, you may already be doing something like this as well, but would you appreciate having something ready to go, off-the-shelf?