Graphql-flutter: Apollo Client 3 beta released - how aligned is GraphQL Flutter architecturally, to incorporate the improvements of AC3 in future?

[shafqatevo]

Hi @HofmannZ and everyone,

Apollo Client 3 (AC3) is aiming improvements in a number of areas, particularly the cache, that are also ideally desired for GraphQL Flutter package. The cache improvement details are here:

https://blog.apollographql.com/previewing-the-apollo-client-3-cache-565fadd6a01e

AC3 goals are here:
https://github.com/apollographql/apollo-client/blob/0e2c4116e1199ef2411ffe4216571ed207826ad8/ROADMAP.md

How aligned is the architecture of this library with AC3 so that contributors can potentially port the improvements to here.

How is the performance of the cache of GraphQL Flutter as compared to Apollo? Has there been any benchmarking like the following one:

https://convoyinc.github.io/graphql-client-benchmarks/

[serendipity1004]

also, would it be possible to use something like react hooks as Apollo does? I am unsure if it is possible (maybe something like Provider does?) but if it can be done, widget nesting can be greatly reduced.

[mainawycliffe]

Great suggestion. There are other issues related to Cache implementation open and we need to find a way forward.

issue #402 and #456

Personally I haven't looked at the improvements but I will and share my thoughts as soon as I can.

[micimize]

graphql / graphql_flutter's design is based on apollo, and these changes don't look like API design changes, but we'd probably have to do a deeper assessment to see what "Redesign the core caching layer" means (#459)

• #354 relates to cache.gc() and cache.evict()
• I just created #458 for typePolicies
• "Entities without an ID are instead stored within their parent object in the cache" we already do this
• I'd consider the new fragment matching approach relatively low priority

• Nobody has done benchmarks, but replacing/reworking the cache is a priority for many contributors (#456)

  Apollo is generally our design reference and API target, and these APIs / improvements will be no exception - though we certainly have less dev hours to throw around than Meteor

[shafqatevo]

Thanks @micimize and @mainawycliffe for summarizing the work required!