You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 ofgrafast
for the consumer of the library but give them the performance benefits.The text was updated successfully, but these errors were encountered: