WatermelonDB and the RxDB-LokiJS project use theLokiJS database as storage, which is anin memory database that regularly persists the data to IndexedDB either on interval, or when the browser tab is closed. By doing so,less slow IndexedDB transaction are used. Keeping and processing the data in memory has the benefit of being much faster, but it also has its downsides:

• Initial page load is much slower when much data is already stored in the database, because all data must be loaded before any database operation can be done.
• All data must fit into memory.
• Data can be lost when the JavaScript process is killed ungracefully like when the browser crashes or the power of the PC is terminated.
• There is no multi-tab-support with plain LokiJS. The data is not shared between multiple browser tabs of the same origin. RxDB handles that by addingits own multi tab handling via theBroadcastChannel module.

On the first page load, Firebase ensures that the local data is equal to the server side state. This means that the client has to be online at application startup which is the reason why Firebase is not completely offline first. To ensure the equalness of client side data, Firebase has to perform several requests to the backend, before the database will respond to queries. This makes the inital page load slow, and it becomes even more slower, the more data exists and has to be validated.

For the PouchDB and RxDB (with PouchDB storage) I used theold Indexeddb adapter.It is much less optimized than thenew adapter, but the new one made problems with returning the correct query results.Theses problems have been fixed on the PouchDB master branch, but I have to wait for the next PouchDB release. I will update the repo when this change can be done.

AWS Datastore does not save any metadata together with the documents. Instead only the plain documents are stored in IndexedDB. They can do this because they only allow simple queries and do not keep a local version history.

All sub-projects use the same port and so cannot be started in parallel.

• You must haveinstalled Node.js
• Clone this project
• In the root folder, runnpm install to install the dependencies.
• In the root folder, runnpm run build to build all projects.

• Runnpm run start:firebase to start the mock server and the production build frontend.

• Or runnpm run dev:firebase to start the mock server and the development frontend server.

• Openhttp://localhost:3000/ to browse the frontend.

The official AWS mock doesnot allow a live replication at this point. So you first have to setup an amplify project in the./projects/aws folder by usingthis tutorial

• Runnpm run start:aws to start the mock server and the production build frontend.

• Or runnpm run dev:aws to start the mock server and the development frontend server.

• Openhttp://localhost:3000/ to browse the frontend.

• Runnpm run start:pouchdb to start the mock server and the production build frontend.

• Or runnpm run dev:pouchdb to start the mock server and the development frontend server.

• Openhttp://localhost:3000/ to browse the frontend.

• Runnpm run start:rxdb-lokijs to start the mock server and the production build frontend.

• Or runnpm run dev:rxdb-lokijs to start the mock server and the development frontend server.

• Openhttp://localhost:3000/ to browse the frontend.

• Runnpm run start:rxdb-dexie to start the mock server and the production build frontend.

• Or runnpm run dev:rxdb-dexie to start the mock server and the development frontend server.

• Openhttp://localhost:3000/ to browse the frontend.

• Runnpm run start:watermelondb to start the mock server and the production build frontend.

• Or runnpm run dev:watermelondb to start the mock server and the development frontend server.

• Openhttp://localhost:3000/ to browse the frontend.

Pull requests are welcomed. Please help implementing more examples:

• Meteor (with the IndexedDB offline first plugin).
• WatermelonDB backend replication.
• AWS Ampflify local backend mock with realtime replication.
• GunDB.