Summary
In fuse we already optimise a lot by going for dataloader,... however it's still hard to observe the potential cost of an operation. We should work on getting insights for this.
Proposed Solution
There are a number of ways to tackle this, we could generate a file that has all the paths of a given operation and cross-reference that in development to how long the server takes to resolve all of that.
We could leverage complexity scoring to have a base heuristic for query-cost.
We could leverage grafast under the hood, grafast already has a base concept of query-plans which makes it easier to reason about query-cost. We own the server-layer so there's a good chance that we can hide the complexity of grafast for the consumer of the library but give them the performance benefits.
Summary
In fuse we already optimise a lot by going for dataloader,... however it's still hard to observe the potential cost of an operation. We should work on getting insights for this.
Proposed Solution
There are a number of ways to tackle this, we could generate a file that has all the paths of a given operation and cross-reference that in development to how long the server takes to resolve all of that.
We could leverage
complexityscoring to have a base heuristic for query-cost.We could leverage
grafastunder the hood, grafast already has a base concept of query-plans which makes it easier to reason about query-cost. We own the server-layer so there's a good chance that we can hide the complexity ofgrafastfor the consumer of the library but give them the performance benefits.