Skip to content

Proposal: move cache related codegen to this project #145

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

Open
BoD opened this issue Apr 25, 2025 · 0 comments
Open

Proposal: move cache related codegen to this project #145

BoD opened this issue Apr 25, 2025 · 0 comments

Comments

@BoD
Copy link
Collaborator

BoD commented Apr 25, 2025

Current situation

As of 2025-04-25.

Generated in Apollo Kotlin by ApolloCompiler:

  • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant