Deleting documents from PouchDB vs keeping them when the user logs out or closes the app

Question

I am developing an single page application that relies on PouchDB for storing state when a user logs in with the app. My application state consists in user data such as email address, first name, etc.

I am new to PouchDB and the concept of storing data in the browser. I am wondering what the best practices are when dealing with issues such as deleting/purging data from PouchDB for a given user...

What are the pros and cons of keeping data/documents in PouchDB/IndexedDB (versus deleting it) when the user signs out or closes and leaves the SPA?

In other words, what would be example use cases of keeping the data and use cases for deleting it upon user log out?

Answer 1

Typical use cases of deleting data once the user logs out might be:

• Deleting authentication tokens: Once the user logs out, any authentication token will become invalid. No need to store them anymore.
• Deleting personal or sensitive data: PouchDB stores it's data in IndexedDB or WebSQL, depending on the browser you're using. As you already found out, data stored there is available "across sessions and browser tabs/windows, within a particular device." Source Therefore you want to keep personal or sensitive data as short as possible.

Note: At best you do not need to store data like mentioned above in PouchDB but this is beside the point.

Use cases for keeping data after log out:

• Keep anything else: Well it depends on your application but if your data is not sensitive, why not store it? Building a offline first app is all about not having to fetch all your data from a remote database so... Only limitation is the storage of the device you're running on and the user's goodwill. Of course this again depends on your application, but you might want to make sure, you're not using up Megabytes of storage for a simple app.

Answer 2

This mostly comes down to user experience versus freshness of data.

PouchDB is meant to allow an app to keep data locally and sync it with a backend system. (CouchDB and Couchbase are both currently supported, as examples of backend servers.) It's also designed to allow multiple clients to make changes.

Most databases expect high-availability of a central system. They are designed to resolve conflicts immediately. With PouchDB you expect conflicts that may not be resolved at client write time.

The core idea is that your app will be used with poor or no network connectivity at times. Keeping information locally means your application can continue to work, even in these situations.

The main tradeoffs:

Keep

• App may still provide useful functionality w/o network connectivity
• Faster response times
• Reduce data transfers across network (avoid resending all data for each invocation)
• May need to pay attention to conflict resolution
• May store excessive amounts of data locally

Delete/Purge

• App can't meaningfully function offline
• App needs to guarantee users only sees updated data
• App uses unacceptable amount of storage

Note PouchDB is a NoSQL database. NoSQL databases can't enforce "ACID" compliance. This means if your app needs data changes to be atomic (transactional), this is the wrong solution.

There are plenty of use cases where eventually consistent data is fine. This can be as simple as having a single client and the backend system "agree" on what's correct. Or it can be a complex system with multiple writers making changes that eventually propagate and get integrated.

There's also security to consider. Will you give the user a way to remove sensitive data in case they're on a shared machine, that sort of thing.

As a final note, you might want to search for 'offline first' as an approach to app development.