Our philosophy behind Apollo Server caching is that a response should only be considered cacheable if every part of that response opts in to being cacheable. Fields that return a non-scalar type (object, interface, or union) or a list of non- scalar types.Īll other schema field s (i.e., non-root fields that return scalar types ) instead inherit their default maxAge from their parent field.Because every GraphQL operation includes a root field, this means that by default, no operation results are cached unless you set cache hints!.Root fields (i.e., the field s of the Query, Mutation, and Subscription types).īy default, the following schema field s have a maxAge of 0 if you don't specify one : The response's scope is PRIVATE if any field 's scope is PRIVATE.If that value is 0, the entire result is not cached. The response's maxAge equals the lowest maxAge among all field s.Calculating cache behaviorįor security, each operation response's cache behavior is calculated based on the most restrictive cache hints among the result's field s: This can be useful when resolving a union or interface field, which might return one of multiple object types. This method enables you to get the default cache hint for a particular object type. To use the directive, you must add the following definitions to your server's schema: In your schema (static)Īpollo Server recognizes the directive, which you can use in your schema to define caching behavior either for a single field, or for all field s that return a particular type.
These details can vary significantly, even among the field s of a single object type. Whether a cached value is global or user-specific.How long a cached value should remain valid.Which field s of your schema can be cached safely.Note that when setting cache hints, it's important to understand: You can define field -level cache hints statically in your schema definition or dynamically in your resolver s (or both).
You can then use this calculation to support any form of cache implementation you want, such as by providing it to your CDN via a Cache-Control header.
Drupal graphql caching upgrade#
Please refer to the upgrade guide and check if this affects you.When Apollo Server resolves an operation, it calculates the result's correct cache behavior based on the most restrictive settings among the result's field s. There have been some small but unavoidable breaking changes. Breaking changesĪll this goodness also has a cost. This should make writing own plugins and identifying problems a lot easier. If the development setting is enabled, the query processor will emit very detailed error reports and exception traces. This finally allows intuitive and easy language handling across query fragments. Execution contextĪ context object is handed down the GraphQL evaluation tree, that allows us to safely pass state to branches. This is also the first step to caching partial query trees. With the improved possibilities to scan an analyse a queries AST even before execution, cache invalidation has become a lot smarter and very specific. Lazy construction of schema plugins and an improved query execution leads to an overall performance boost. This brings some exciting new improvements and possibilities: Improved performance AKA: “The big webonyx/graphql-php migration.”Īfter having an eye on it for quite some time now, it’s been decided that the GraphQL module for Drupal should switch to the more mature webonyx/graphql-php library for parsing and executing.
0 kommentar(er)
