Operation cache keys are very long (full document + variables)
We should consider making keys a hash or uuid. Not a hashCode though 馃槵
Objects that are not equal are allowed to have the same hash code
@lookfirst moving discussion here.
One option would be to use uuid.v5 for deterministic uuids. Maybe something like $documentUuid/$operationName($variables)
I guess apollo just caches by $operationName($variables) (I guess they don't support anonymous operations):

@micimize I think in Apollo it is actually
[GraphQLType]: {
field(variables): value
}
And then the same goes recursively down per value. At least for the in-memory de-normalized cache it is so. Maybe some less advanced cache implementation cares about unique operation keys, because it caches the whole responses instead of every entity.
I think this API is limiting
https://github.com/zino-app/graphql-flutter/blob/519381cd1c57515fd26cedb33c68a68d563a6eac/packages/graphql/lib/src/cache/cache.dart#L1-L7
Instead of reading and writing with a key, we should read/write with a whole qurey+variables then it's cache's responsibility to come up with their own key.
Also, the de-normalizing cache will need the query document + variables to determine what arguments were used on a field. It cannot do it only by looking at the response data.
There is also @connection to consider. Some times, you don't want every variable cached as it would pollute the cache and make it totally ineffective. Imagine sorting a table of data on the server. You don't want to cache by sort key. Took me a bit to figure this out.
closed in v4 by using normalize #648
Most helpful comment
@lookfirst moving discussion here.
One option would be to use
uuid.v5for deterministic uuids. Maybe something like$documentUuid/$operationName($variables)I guess apollo just caches by

$operationName($variables)(I guess they don't support anonymous operations):