R&D: Create a PoC of offline-cache without indexedDb

[pkarw]

What is the motivation for adding / enhancing this feature?

The indexedDB caching prooved to be a problematic solution because of:

• problems with network-errors handling (we need to pass over the network errors because Service Worker is not returning data for API calls - we're simulating that we're fine with getting the data from idnexedDb)
• indexedDb sometimes has really strange response times (>800ms) and sometimes even kind of deadlocks (when You've got few tabs opened)

1. Currently, we're populating the cache in search.ts

This is PER-QUERY cache that we can replace with Service Worker cache. We can switch-off this logic in this PoC

IMPORTANT NOTE: Service Worker CAN NOT cache the POST requests - currently all the api/rest and graphql requests

We can easily modify the search adapter to send the GET requests + the searchQuery as a base64 encoded GET parameter instead of JSON body (check this) - and then modify the vue-storefront-api to unpack the GET-based search query and pass it to Elastic in correct format.

However, we CAN NOT add service worker caching for graphQL queries (read on graphQL supprt)

So - this service-worker only caching strategy should be disabled automatically when the search.engine=graphql and use the current indexed-db based cache as there won't by any offline mode otherwise.

The same in the situation when service-worker cache is not available at all

2. Moreover, we're setting the cache of products by SKU (for having the product pages available even for products that user hasn't clicked; The cache is populated in the product/quickSearchByQuery

There is no network call for product data as we're using the product data pre-fetched in the product/list action

This cache won't be replaced by Service Worker. In fact - we probably need to keep this logic to avoid additional network-calls on product page (product/single vuex action) because of ...

3. If You went to "Women" all products will be available even when offline because we do have a per-sku cache - which is used in product/single action)

The question is - how to keep this "pre-fetching" enabled without using the indexedDB? I mean per-sku cache. Service worker cache will work on full queries (product/list results).

Probably: we can store the per-sku cache (2) just in kind of in-memory hash - as the product/list action is always called first (as user is browsing first the category/search results - then selecting the product - so in product/list we can populate the memory cache allowing product/single to use it)

Our indexedDb driver is using the in-memory stores for speed optimization already

Notes:

• the same logic as described in here is being used for category actions
• to remove indexedDb from being used we should modify product vuex actions either modify; the storage.ts is used also for accessing localStorage - shopping carts, user tokens etc and probably it shouldn't be modified
• we should populate the in-memory cache on the persistent data we received from Service Worker
• the /api/* requests are excluded from Service Worker -

What are the acceptance criteria

• user can go to Women category - switch of the Internet - and still being able to access the products on the page (even these that he/she hasn't visited before - so the data should be prefetched - optimally without aditional network calls)
• the current / legacy indexedDB cache should still be in use for a) browsers that are NOT supporting service workers, b) when search.engine = graphql as graphQL is only available via POST and no service-worker caching is possible on these requests

Can you complete this feature request by yourself?

Additional information

[pkarw]

@NataliaTepluhina could You please reframe this issue's description and put it into docs as kind of "How Offline Mode works" ?

[pkarw]

Any other ideas how to improve this - feel free to comment :)

[filrak]

Ill take it :)

[pkarw]

@filrak it seems like @patzick already took it :) we discussed it yesterday evening and he’s already investigating this issue

[filrak]

Haha no problem. Just please consult it with me. We should obviously use Workbox for this

[filrak]

And take this into account https://github.com/DivanteLtd/vue-storefront/issues/1994

[pkarw]

We need to consider this one as well: https://github.com/DivanteLtd/vue-storefront/issues/1698