Pwa-studio: [feature]: Implement graphQL query caching at Service Worker Level.

[revanth0212]

Is your feature request related to a problem? Please describe.
Related to #1673

Describe the solution you'd like
As of today, we are not caching graphQL query results. This will be useful when it comes to offline experience and also quick instant responses when it comes to data that might not change often like storeConfig.

1. When a graphQL call is made, analyze if it is a GET or POST equivalent. If GET, use the network first approach and store the data before returning to the client for future use.
2. If the network is taking too long, return the data in the cache and update the cache when the network comes back with the data.

Please let us know what packages this feature is in regards to:

• [x] venia-concept
• [x] venia-ui
• [ ] pwa-buildpack
• [ ] peregrine
• [ ] pwa-devdocs
• [ ] upward-js
• [ ] upward-spec

[awilcoxa]

Additional discovery required for application of Apollo functionality here, need to determine need to have this caching at the SW vs Apollo. @revanth0212 @zetlen

[supernova-at]

Here's the Apollo documentation (and https://www.apollographql.com/docs/react/caching/cache-interaction/).

Emphasis mine:

Apollo Client uses a normalized, in-memory cache to dramatically speed up the execution of queries that don't rely on real-time data.

If we don't want to use the cached version of a query, we can just use a different fetchPolicy for that query.

[cherdman]

https://jira.corp.magento.com/browse/PWA-52

[dani97]

Here's the Apollo documentation (and https://www.apollographql.com/docs/react/caching/cache-interaction/).

Emphasis mine:

Apollo Client uses a normalized, in-memory cache to dramatically speed up the execution of queries that don't rely on real-time data.

If we don't want to use the cached version of a query, we can just use a different fetchPolicy for that query.

There are queries in Magento which should not be cached, like isEmailAvailable query when creating customer account. So Apollo to SW, we can use the fetch policy of apollo.

[revanth0212]

I am not sure of the Apollo policy. Definitely something to look into. Meanwhile, it is no possible to cache POST calls in the browser cache storage. There is an open issue in SW Spec repo to enable this https://github.com/w3c/ServiceWorker/issues/693. Although this is an open issue, I am not sure if this will be implemented any time soon, since this issue was open since 2015. There is a workaround for caching POST calls but the work involved is not justifiable of the performance benefit we will be getting back. Hence removing this issue from the Performance Milestone for now. I will check back in the future. It can be a good first issue as well if someone wants to work on it.

[zetlen]

This should stay open because we don't strictly need to use CacheStorage to cache things in the ServiceWorker. It is the simplest approach, and ServiceWorker is designed for it, so @revanth0212 is right that we should use CacheStorage as soon as we can.

However, ServiceWorkers can still intercept fetches with non-GET HTTP methods. We can store responses in an indexedDB and build Response objects manually to respond from cache instead of keeping Responses in CacheStorage directly. It's something to research.