Skip to content
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

Add sections on using @cost and @listSize to demand control docs #5839

Merged
merged 6 commits into from
Aug 21, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changesets/docs_tninesling_cost_docs_update.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
### Add sections on using @cost and @listSize to demand control docs ([PR #5839](https://github.com/apollographql/router/pull/5839))

Updates the demand control documentation to include details on `@cost` and `@listSize` for more accurate cost estimation.

By [@tninesling](https://github.com/tninesling) in https://github.com/apollographql/router/pull/5839
58 changes: 58 additions & 0 deletions docs/source/executing-operations/demand-control.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -360,6 +360,21 @@ Looking at the top N operations, you may see that the estimated costs have been

All operations except `ExtractAll` are in a range of acceptable costs.

<MinVersion version="1.53.0">

#### `@listSize`

</MinVersion>

If some of your fields have list sizes that significantly differ from `static_estimated.list_size`, you can provide the router with more information.

The `@listSize` directive can be configured in multiple ways:

1. Use the `assumedSize` argument to define a static size for a field.
2. Use `slicingArguments` to indicate that a field's size is dynamically controlled by one or more of its arguments. This works well if some of the arguments are paging parameters.

Learn more about the `@listSize` directive [here](/federation/federated-schemas/federated-directives/#listsize).

### Enforce cost limits

After determining the cost estimation model of your operations, you should update and enforce the new cost limits.
Expand Down Expand Up @@ -440,6 +455,49 @@ Assuming each review having exactly one author, the total cost of the query is 2

</ExpansionPanel>

<MinVersion version="1.53.0">

#### `@cost`

</MinVersion>

You can further customize the cost calculation with the `@cost` directive. This directive takes a `weight` argument which replaces the default weights outlined above.

Revisiting the products query above, if the `topProducts.name` field is annotated with `@cost(weight: 5)`, then the total cost of the query increases to 56.

<ExpansionPanel title="An example annotated Products schema">

```graphql
type Query {
topProducts: [Product]
}

type Product {
name: String! @cost(weight: 5)
reviews: [Review]
}

type Review {
author: Author!
}

type Author {
name: String!
}
```

</ExpansionPanel>

<ExpansionPanel title="Example query's updated cost calculation">

```text disableCopy=true showLineNumbers=false
1 Query (0 cost) + 6 product objects (6) + 6 name scalars (30) + 10 review objects (10) + 10 author objects (10) + 10 name scalars (0) = 56 total cost
```

</ExpansionPanel>

Learn more about the `@cost` directive [here](/federation/federated-schemas/federated-directives/#cost).

### Estimated and actual costs

For an operation with list fields, the router must run the operation to get the actual number of items in its lists. Without actual list sizes, the cost of an operation can only be estimated before it's executed, where you assume the size of lists.
Expand Down
Loading