Skip to content

Commit

Permalink
docs/execution-pipeline.md: grammar and text style corrections
Browse files Browse the repository at this point in the history
  • Loading branch information
valbers committed Dec 14, 2024
1 parent b6fb37f commit 036937c
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion docs/execution-pipeline.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ As the name suggests, `ExecutionPlan` and its components (a tree of objects know
- Combining information from the query AST (resolved fields / aliases) with server-side information about them (field and type definitions);
- Preparation of the hooks in the execution chain that will be supplied with potential variables upon execution.

Spliting planning and execution phases is a good idea when you have the same GraphQL query requested many times (with potentially different variables). This way you can compute the execution plan once and cache it. You can use `executionPlan.DocumentId` as a cache identifier. DocumentId is also returned as one of the top level fields in GraphQL response, so it can be used from the client side. Other GraphQL implementations describe that technique as **persistent queries**.
Splitting planning and execution phases is a good idea when you have the same GraphQL query requested many times (with potentially different variables). This way you can compute the execution plan once and cache it. You can use `executionPlan.DocumentId` as a cache identifier. `DocumentId` is also returned as one of the top level fields in the response, so it can be used from the client side. Other GraphQL implementations describe that technique as **persistent queries**.

## Execution phase

Expand Down

0 comments on commit 036937c

Please sign in to comment.