Hello! Do you have a recommendation for some stati...

# apollo-kotlin

[Eduard Boloș]

Hello! Do you have a recommendation for some static analysis tool that is able to detect if in a GQL query the id field is not included for objects that have such a field? Or do you think that this is something that could be part of the Apollo tooling? We are using id as the cache key in our CacheKeyGenerator implementation, and it would be useful to have such a check so that people's queries don't mess up the cache by mistake (we had several bugs and crashes due to this 😅)

[mbonnin]

Sounds like a good candidate for a compiler plugin

[mbonnin]

There is ApolloCompilerPlugin.documentTransform that is more geared towards modifying the document (adding the "id" field automatically) but I guess you could also just return the document "as-is" and just run checks

[mbonnin]

Out of curiosity, is your field always named "id" and if yes, is there any reason your backend team doesn't use Relay global identification using a Node base interface?

[mbonnin]

Because if you do, we've been discussing recently about something like

extend interface Node {
  id: ID! @keyField
}

which should work automatically (event though there might be edge cases but I'm unclear about that part)

[bod]

(Also, a bit different from what you're asking but related: https://github.com/apollographql/apollo-kotlin-normalized-cache/issues/117)

[Eduard Boloș]

There is ApolloCompilerPlugin.documentTransform that is more geared towards modifying the document (adding the "id" field automatically) but I guess you could also just return the document "as-is" and just run checks

Cool, we already have a compiler plugin to make generated sealed classes for GQL enums parcelable 😄 Currently I implemented the check in a hacky manner in the CacheKeyGenerator by using some reflection, so this sounds like a better solution to look into, thanks!

Out of curiosity, is your field always named "id" and if yes, is there any reason your backend team doesn't use Relay global identification using a Node base interface?

Yes, it's always named "id" afaik. No idea why we don't use a Node interface for all objects, maybe due to lazyness? But if we did, with the id field being annotated as @keyField, would that make it being pulled into the query automatically by Apollo with this change you are discussing?

[mbonnin]

with the id field being annotated as @keyField, would that make it being pulled into the query automatically by Apollo with this change you are discussing?

Yep, that's the general plan

[Eduard Boloș]

Btw, is there some issue I can subscribe to in order to stay up to date with the progress of this proposal?

[mbonnin]

This is probably the closest: https://github.com/apollographql/apollo-kotlin-normalized-cache/issues/141

[wasyl]

For checking that the id is fetched if a type has it, you can also use https://github.com/graphql-hive/graphql-eslint. It has also some other checks like codestyle, not fetching duplicate fields, not having unused fragments etc.

[Eduard Boloș]

Ah, that's pretty cool, too bad that it doesn't integrate with Android Studio as well and that it needs an NPM environment and eslint to run 😄 I will put it in the list of alternatives to consider, thanks!

[mbonnin]

The unused fragment seems like a warning the Apollo compiler should probably incorporate 👀

[mbonnin]

Formatting is a whole new class of problems I wouldn't necessarily dive into but we have warnings on unused fields in the IJ plugin. unused fragments feel like something that belongs there

[wasyl]

IJ does not report unused fragments from what I see, but does show all fields as unused 😄 I'll be reporting some issues around unused inspections in Apollo plugin btw, soon™ 😛

And yeah, the eslint requires completely separate machinery to run which is unfortunate, but I did find it useful regardless — it's fast, easy enough to run on CI, was quite easy to extend, and generally was a useful bit of additional linting and CI-checks for repo which does not have Gradle in it in the first place (we kept graphql shared between platforms in a separate repository). For me its similar to having a quick ktlint vs IDE checks/compiler warnings which are more difficult to run and automate