Open
Description
Current situation
Some code is generated by Apollo Kotlin by ApolloCompiler
(unchecked), while some code is generated in this project via an Apollo compiler plugin (checked).
The intent is to move the remaining items to this repo.
- Type key fields, derived from
@typePolicy
- Addition of key fields and
__typename
to selections - Max ages, derived from
@cacheControl
- Embedded fields, and connection types (
Pagination
object), derived from@typePolicy
- Field key argument, derived from
@fieldPolicy
- Compiled selections
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 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:
- 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
CompiledField
s 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.
Metadata
Metadata
Assignees
Labels
No labels