Apollo-android: How can we prevent the __typename field being added to generated queries?

[adrian-baker]

[sav007]

There is no way to do this as it very critical field to correctly resolve fragments, inline fragments, normalized cache etc.

[adrian-baker]

The code generator knows the typename at generation type though, so technically there is no need to retrieve it every time at runtime, is there?

We have a query with a large list of small entries, for which repeating typename for each has a large impact on the resulting payload size (and serialization/deserialization cost).

[sav007]

The code generator knows the typename at generation type though, so technically there is no need to retrieve it every time at runtime, is there?

no code gen knows about the type name it request fields on, but it can be an interface or union:
https://graphql.org/learn/schema/#interfaces so the concrete typename comes with the response.

[adrian-baker]

1. In that case there is no need for __typename if the type is not a union or an interface, yet it appears to be added for all types.

2. Even for the case of a interface/union, the return value can safely be deserialized into a higher level type without knowing the concrete type name, so even in this case I don't see that __typename is necessary. The query can only issue fields in a subtype if they do a fragment with ... on, specifying explicitly the type, which means the additional __typename field is still redundant.

[sav007]

Here is a use case:

query TestQuery {
  hero {
    ...HeroDetails
  }
}

fragment HumanDetails on Human {
  name
}

Requested field hero is type of interface Character, so in the response we can expect for example another concrete type of this interface Droid and as our fragment defined on Human we shouldn't parse it. To proper handle this we need to understand what type is returned by requesting __typename.

I can agree that we shouldn't probably request __typename for every fields but rather than on those having fragments and inline fragments, I don't remember why it was decided to have them everywhere maybe just to be consistent but I can try to dig into and see what I can do.

Does this make sense to you?

[adrian-baker]

Right, yes, thanks for explaining. Though - a minor point - in the example above, you can tell by the presence of the name field in the response (if name is present, it's a Human). I can see though that there will be other cases where this sort of rule isn't possible.

In any case, not adding __typename for non fragments would certainly resolve our issue (we're not using them for the problem query).

[sav007]

After working on the PR I realized that removing __typename field generation will break normalized cache as it totally depends on this field, as any other query with inline / regular fragment can't be resolved from cached response as __typename fields is missing. Closing this issue as won't fix.

[adrian-baker]

What if caching is not used? It seems inefficient if apollo client is adding a lot of overhead (ie high volume of additional fields serialized) for features not used (caching, polymorphism).

[sav007]

Alright, alright we can make it configurable.

[SnowyCoder]

Just throwing my two cents: Even if the name doesn't seem like much it can be quite heavy if the site is downloading an array of data (for example readings from a sensor to build a graph).

[martinbonnin]

I'm curious how much network bandwidth is actually saved by removing the __typename fields. My guess is that these fields would gzip very well so in the case of an array, it will run-length-encode all the identical __typename fields and the overhead would be very small.

[adrian-baker]

The real overhead is not bandwidth, but serialization and deserialization cost.