Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client-side caching #77

Open
julianrubisch opened this issue Jan 31, 2021 · 0 comments
Open

Client-side caching #77

julianrubisch opened this issue Jan 31, 2021 · 0 comments

Comments

@julianrubisch
Copy link
Contributor

There are two ways in which this could be tackled:

  1. the „canonical“ way would be via PWA/Service worker. The problem is that only one SW per domain can exist, so people would have to integrate this with their own implementations. This would boil down to a (hard and ungrateful) documentation task.

  2. We could also go and roll our own implementation, as for example with the Turbolinks cache store and sessionStorage. The problem is that it only holds a few MB and isn’t expireable: https://stackoverflow.com/questions/15171711/expiry-of-sessionstorage

this could also be a case for IndexedDB/localForage, but still we would have to code the expiration logic ourselves: https://stackoverflow.com/questions/35511033/how-to-apply-expiry-times-to-keys-in-html5-indexeddb/35518068

That said, we could provide a unified interface for both Turbolinks cache storage and fragment caching via localForage

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant