Apollo rough spots for Shopify.md

• Typings. We developed our own typescript/ GraphQL thing (https://github.com/Shopify/graphql-tools-web/tree/master/packages/graphql-typescript-definitions). A few reasons:
  • Types alongside GraphQL files themselves
  • Good tree shaking for “real” enum types
  • Include the type in the GraphQL document definition so that types for Query/ graphql were automatically inferred
  • Better typings for things like variables
  • Smart types to support some testing infrastructure like https://github.com/Shopify/graphql-tools-web/tree/master/packages/graphql-fixtures
• Server rendering: we wrote our own bridging to make it work with the rest of our server side extraction (https://github.com/Shopify/quilt/tree/master/packages/react-effect-apollo)
• Size: Apollo is about 30K gzipped all told, maybe a little more with the dependencies
• Speed: seeing some expensive queries take 30+ ms to actually apply to the cache
• Cache: not really clear how much the cache API is meant to handle. We have some things we’d love to see, though:
  • Persistence: having some way of automatically persisting segments of the cache for (for example) our service worker
  • “Staleness”: having the cache keep some notion of staleness so that fetch strategies can be smarter about keeping data that has been queried recently, but cache-and-network or network-only for results past a certain age
  • Mutations: this is probably one of our biggest pain points. We have hundreds of mutations. They may end up affecting many different queries, but we don’t want them to have to know which ones. Right now, we basically just have to treat the cache as always being stale. We’d love to be able to do things like refetching all queries that depend on a field that we know to be affected by a mutation (i.e., ever ProductConnection gets re-queried when we do run the DeleteProduct mutation. We’d also love updaters to not operate on the query/ fragment level, but to operate on the types, too.
  • It has never been clear how things like deletion should be handled in the cache. We delete a resource, but now the cache does not actually reflect the query (first: 10 but only 9 in cache, etc)
• Mutation components: haven’t worked out great for us because we have so many on a given components, too much nesting