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
Type key fields, embedded fields, and connection types, derived from @typePolicy
Field key argument, derived from @fieldPolicy
Added key fields and __typename in selections
Generated in this project via an Apollo compiler plugin:
Max ages, derived from @cacheControl
Proposal
Move the codegen related to the cache currently in Apollo Kotlin to the Apollo compiler plugin in this project.
Advantages
Complexity: just from a code organization standpoint it would make sense for one project to deal with the cache concerns (counter argument: it also makes sense for all the codegen to reside in one place, as currently).
Flexibility/ease of maintenance: remove some coupling between the 2 projects, making it easier to make this one evolve. For instance, in Allow for type to be omitted when calculating Cache keys #102 we'd like to add arguments to @typePolicy/@fieldPolicy. Having to do this in the main project adds some friction, e.g. releases of both projects need to be coordinated.
Drawbacks
The pieces useful for the cache currently generated by ApolloCompiler are directly accessible from Executable, meaning the cache internals can access them directly. Moving that logic here would generate them in a dedicated object (like currently for the max ages), which needs to be passed to the cache configuration by the client code. This makes the API a bit less ergonomic / the client code a bit more verbose.
Considerations
In no particular order:
By "moving" we probably mean duplicate to begin with - as we'll want to keep the "classic" cache working
We should also move (duplicate) @typePolicy/@fieldPolicy from kotlin_labs to cache. Thanks to @link these directives should be seen as distinct by the codegen even if they have the same name, thus we won't have duplicated generated code.
The ability to transform operations to add key fields and __typename in selections has been added to the v4 compiler plugin. This means the cache project will need to depend on that version, or that this feature will need to be back-ported to v3.
Currently we have duplicated information in the CompiledFields and the operation text in the generated Operations
A lot of what the cache does is equivalent to GraphQL execution. In apollo-kotlin-execution world, a schema is needed.
The text was updated successfully, but these errors were encountered:
Current situation
As of 2025-04-25.
Generated in Apollo Kotlin by
ApolloCompiler
:@typePolicy
@fieldPolicy
__typename
in selectionsGenerated in this project via an Apollo compiler plugin:
@cacheControl
Proposal
Move the codegen related to the cache currently in Apollo Kotlin to the Apollo compiler plugin in this project.
Advantages
@typePolicy
/@fieldPolicy
. Having to do this in the main project adds some friction, e.g. releases of both projects need to be coordinated.Drawbacks
ApolloCompiler
are directly accessible fromExecutable
, meaning the cache internals can access them directly. Moving that logic here would generate them in a dedicated object (like currently for the max ages), which needs to be passed to the cache configuration by the client code. This makes the API a bit less ergonomic / the client code a bit more verbose.Considerations
In no particular order:
@typePolicy
/@fieldPolicy
from kotlin_labs to cache. Thanks to@link
these directives should be seen as distinct by the codegen even if they have the same name, thus we won't have duplicated generated code.__typename
in selections has been added to the v4 compiler plugin. This means the cache project will need to depend on that version, or that this feature will need to be back-ported to v3.CompiledField
s and the operation text in the generated OperationsThe text was updated successfully, but these errors were encountered: