-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract @cost and @listSize to query planner's subgraph schemas #5707
Conversation
…t to propagate the directives
@tninesling, please consider creating a changeset entry in |
CI performance tests
|
apollo-federation/src/query_graph/extract_subgraphs_from_supergraph.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good! Thank you for making sure it's right away added to the rust implementation!
The only change I'd like to ask for is adding Object and Scalar types with @cost
to the two tests you've got here. Otherwise a few clarification comments/questions.
I am away this next week and don’t want to block you from merging this. The only thing that's important before merging is using the Object Type Definition and the Scalar Type Definiton with |
Thanks, Iryna. This was a great catch, and made me realize I need an equivalent patch for the JS version |
…n with some macros
This PR follows up on apollographql/federation#3074, which defined the new
@cost
and@listSize
directives. These will be used by the demand control plugin to score the cost of operations. In the scoring algorithm, the plugin scores FetchNodes in the query plan based on their respective subgraph schemas. This means those extracted subgraph schemas must include these directives, which are copied over from the supergraph.Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩