This post illustrates an issue our developers have run into when trying to convert their service from a traditional BFF into a federated subgraph.
It's unclear how to maintain the most optimal set of network waterfalls throughout the combined backend while keeping an idiomatic client-facing schema. Specifcially, if a resolver in a selection set to a subgraph is slow, it blocks the yielding of the subgraph response. (See the query plan of the example below.)
# router -> subgraph query
query MyQuery__subgraph__0 {
foo {