Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

[Sync] More efficient storage provider #291

Open
wtrocki opened this issue Mar 11, 2019 · 4 comments
Open

[Sync] More efficient storage provider #291

wtrocki opened this issue Mar 11, 2019 · 4 comments
Labels
community Community good first issue Good for newcomers sync Sync issues

Comments

@wtrocki
Copy link
Contributor

wtrocki commented Mar 11, 2019

Motivation

Use more efficient storage solution that do not perform JSON.stringify etc.
Proposed option: https://github.com/localForage/localForage

@wtrocki
Copy link
Contributor Author

wtrocki commented Mar 11, 2019

ping @darahayes @StephenCoady

@wtrocki wtrocki changed the title [Sync] [Sync] More efficient storage provider Mar 11, 2019
@wtrocki wtrocki added good first issue Good for newcomers community Community sync Sync issues labels Mar 11, 2019
@darahayes
Copy link
Contributor

Yeah according to the upstream documentation localForage is 'supported out of the box' so it would be worth testing out as a drop in replacement. https://github.com/apollographql/apollo-cache-persist#storage-providers

@wtrocki
Copy link
Contributor Author

wtrocki commented Mar 11, 2019

Yes. I have noticed huge performance gains on application startup even on simple showcase dataset. Rehydrating localstorage takes long time when is persisted as string (JSON.strinfigy). We need that as default option (it is simple to pass that into the showcase application but I have been using this for some time now and it seems that it will be seamless transition.

@wtrocki
Copy link
Contributor Author

wtrocki commented Mar 13, 2019

TODO! Migrate this to jira.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
community Community good first issue Good for newcomers sync Sync issues
Projects
None yet
Development

No branches or pull requests

2 participants