Skip to content

Proposal: move compiled selections codegen to this project #145

Open
@BoD

Description

@BoD

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 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions