ROADMAP

[wtrocki]

The issue used to collect and stage all community ideas.

Version 1.0.0

Features

• [ ] Storage layout abstraction #132
• [x] Non async workflow #89

Bugs/Tech Debt

• [ ] MonoRepository #132
• [ ] Content filtering
• [x] Improvements for storage interface
• [x] Package updates (Merging Renovate logs)
• [x] Upgrade config for rolup
• [x] Verifications for latest LocalForage, AsyncStorage etc. This will help with closing issues that may be outdated.
• [x] Bundling fixes #144
• [x] Async API

Docs

• [x] Document default and performant storage provider for the web
• [x] Ionic support #47

Feel free to suggest any changes that should land in the follow-up versions. Looking for contributors and ideas to move this package forward.

[FezVrasta]

Is the async-ness of persistCache really needed? It's a bummer I have to re-arrange my whole application just to make the Apollo client asynchronous and show the loading page/skeleton.

[wtrocki]

Most of the storage options like IndexedDB or AsyncStorage is asynchronous so that is why persistCache is async. The library allows users to pass their own storage that can be synchronous in theory.

@FezVrasta Would it be possible to create a separate issue for a conversation about this matter. There is no need to rearrange the whole application as ApolloProvider will support async await syntax. From this and other issues It made it clear for me that we should provide examples for each framework on how to do things effectively.

[FezVrasta]

I'm not sure if https://github.com/apollographql/apollo-cache-persist/issues/89 tries to address my same concern or not.

I know how to implement an asyncronous apollo client on my React app, but that requires me to create a loading page while the apollo client is being prepared, and since I can't just return 'Loading...' I need to create a complex "skeleton like" loading page.

[wtrocki]

Let's chat on the issue directly.

[lukadriel7]

Hello, thanks for the great work. I have a question. I realized that wtrocki, who seems to be the main person working on this package, is also working on https://github.com/aerogear/offix . That package lacks on the documentation side but I wanted to know if it is the one that should be considered over apollo-cache-persist since it seems to be more active.

Thanks again

[wtrocki]

@lukadriel7 Thanks for letting us know. Offix is an offline extension for Apollo GraphQL and by no means is targeting to replace apollo-cache-persist.

In fact, apollo-cache-persist is a critical element to achieve offline capabilities in offix and this is why I'm involved to make this package better and also contribute back to the amazing Apollo community. If you have any ideas for documentation improvements for Apollo-cache-persist or Offix feel free to create a new issue.

EDIT: Apollo Cache persist repository was not active for the last year, but we starting to speed up things a little bit so the community can expect next release sooner and more releases to follow. There will be also tons of amazing features coming from the Cache invalidation feature from Apollo 3.0 that Apollo Cache Persist will need to adopt at a later stage. We are just starting to make improvements in cache persist and collect voice from the community so please stay tuned for updates.

[lukadriel7]

@wtrocki that is great to know, I will be following this package more closely then. Thank you very much

[intellix]

Plans for TTL support?

[wtrocki]

@intellix This will be done in apollo cache directly. Persistence will need to just catch up with evicted items.

[hariDasu]

I am hesistant to migrate to apollo on react native for one reason, and that is because the cache is in-memory. I am maintaining a react native/redux/redux-sagas application and have been unable to successfully utilize redux/redux-persist as our persistent storage engine because even when setting the options to permit storage over 2MB and using redux-persist-fs-storage when the data loaded into memory gets larger the navigation between and within screens sees a noticeable slowdown. as an alternative i've opted to use redux-persist to hold state management data (loading indicators etc) and some minimal data in memory to speed up client side interaction with data, but am now utilizing typeORM/SQLite as the persistent storage engine. my question is:

are you considering adding SQLite as a storage engine either in conjunction with or as an alternative to the in memory cache for persistent storage?

[wtrocki]

So there is this discussion happening in the community for more than year on how to move the cache from single key storage to actuall database/multikey solution. Imagine that all InMemory based storage gets saved as individual tables and keys. There is no problem to use SQLLite with CachePersist at the moment but what you can do is to simply have a build wrapper that will spread apollo-cache into individual tables as you wish and it will always will need to override them all.

Making any radical change inside this library will break a lot of clients and also it will make it incompatible with other cache solutions (like Hermes) that some people might not like. That is this change were not made despite many attempts (PR's to do so).

Simply replicating redux-persist storage and understanding of the apollo cache id composition (by default Type:ID) can do wonders inside app itself with little effort and tradeoffs. I think there are couple unmaintained forks for InMemoryCache that have persistence inside and there are couple wrappers that adapt SQL lite api into local storage API. Problem for the moment that save will always save entire database - there is no way to know what was changed unless having direct access to the InMemoryCache implementation.

As for store limitation - have you tried using IndexedDB on the web - depending on the browser your changes will end up in SQLlite like db anyway.

[hariDasu]

Our web client is not concerned with offline data access so we have neither considered nor implemented caching in the browser. For now typeORM/redux will work for us in react native but I will stay tuned for future updates on this matter thank you for the detailed response it was very informative

[vicary]

It would be great if this can support the typeorm since their SQL.js driver already has an option of useLocalForage.