Hi, all! Probably this is not 100% Apollo specific...

# apollo-kotlin

[Eduard Boloș]

Hi, all! Probably this is not 100% Apollo specific, but I guess that it's the most appropriate audience to ask this question.

TL;DR: Is there a way with static analysis to tell which fields are used, in order to avoid breaking GQL changes on the backend?

Long version: In our project, it happened a couple of times this year that someone (one time it was me 😄) made changes to the backend that broke our Android clients. We already have a check in place on the CI that should stop us from introducing breaking changes in the GQL schema (when compared with the latest existing schema), but this check can be overridden, as sometimes there is a legitimate reason why you want to introduce that breaking change (for instance, there is no client using the fields you are removing/changing, and you want to make the API better). The problem is that sometimes people are not aware that fields that they are removing/changing in a non-backwards compatible way are actually being in-use, thus breaking some versions of the app.
What I am curious to find from you is if you are using or you are aware of some static analysis tooling that can tell you what fields are used in the queries and mutations in the application's *.graphql files and that would raise an error if someone would try to introduce a breaking change in the GQL schema based on the information of the used fields.

If relevant, we are using Apollo-Android on the client-side, Graphene-Python on the backend, and everything is in a monorepo.

[wasyl]

Note that to make this 100% reliable you’d have to check the proposed schema against not just current client queries, but all queries that can be used by the clients in the wild, so probably couple of previously released versions that the users are still using

[wasyl]

That said I’m not aware of such tool. I’m curious what do you use to check for breaking changes in the schema in general though, is it something publicly available?

[Eduard Boloș]

True, actually more than a couple of versions back, as our users are very slow to update their app, mostly because they lack good Internet 😞
The way we check for breaking changes currently is by using @graphql-inspector/cli. Basically, for each build, we generate the current backend schema, and in each PR we check with graphql-inspector whether there is a breaking change or not compared with the base (https://www.npmjs.com/package/@graphql-inspector/cli#user-content-compare-schemas). What we would like on top of this is to be able to tell whether it's safe to ignore this check or not, based on the actually used fields in the app. (We could point to different versions of the app using tags, that wouldn't be a problem).

[Eduard Boloș]

This setup was already here when I joined a few months ago, now looking into this tool makes me think whether we could use the "check coverage" feature of it (https://www.npmjs.com/package/@graphql-inspector/cli#user-content-check-coverage) to achieve this. I guess will have to investigate more.

[mbonnin]

"check coverage" looks interesting. It will not have the "dynamic" of the usages i.e how far should you check for older versions but I guess you can couple that with the Google Play stats to get a pretty good understanding of your API usage.

[mbonnin]

@Eduard Boloș I filed this issue on the apollo cli repo: https://github.com/apollographql/rover/issues/434. Feel free to chip in!

[taso]

Not what you want exactly but your unit test coverage over the generated code would also tell what are used or not.

[Dariusz Kuc]

While the inspector could be used to check breaking changes between schema files I believe you would need to also capture some metrics on figure out which fields are requested. Afaik there is no free solution (eg Apollo does offer it) but you could certainly build your own. Not familiar with Python landscape but I'd assume you should be able to use open telemetry for tracing or something like prometheus for metrics.

See
• https://www.apollographql.com/docs/studio/schema-checks/