PouchDB

This week we have decided to some changes to the application I’m currently working on for the better. Normally, server web applications would have a dedicated database to read, write and store crucial data. That was the case for this application as well, until Dr Shawn got the idea that we do not need to keep this single database at all. What? That was my reaction as well.

Basically, we already knew that the application would interact with cloud storage services. The purpose of using a cloud storage service, is to, of course, store important files or documents remotely, as backup mostly. A database is also a file itself. So knowing that, why store the database file locally, when you can just store it in the cloud? We would save some storage space on wherever the server application is running at. To actually read and write data to that database, it would temporarily be stored in a cache as soon as the application mounts the remote filesystem. When it is time to flush the cache, the database file would be saved to the remote storage.

Each user may not necessarily use one cloud storage service only. Schools may give their students a cloud storage service to store their school projects in it, e.g: Google Drive. Companies may also do the same with their employees. The user themselves may also configure another cloud storage service to store their own personal projects. With that being said, given our new way of storing databases, one user would have one database file in each cloud storage service that he or she use. That is totally fine as I mentioned that each of the user’s cloud storage service may contain separate projects for different purposes.

We could also take this a step further by storing the database within the browser itself. PouchDB is an in-browser database that allows you to store data locally on the user’s browser and also sync data with a CouchDB based database on the backend. The ability to store data in the browser itself means that the user could still use the application even in offline conditions. Once the user is connected to the internet again, we could sync data with our remote CouchDB database, using the CouchDB Replication Protocol. Synchronization is done by sending HTTP requests to a CouchDB REST API endpoint. This could be done as PouchDB stores data as JSON documents. PouchDB is a NoSQL database, which means that there is no structure or schema predefined to store data, and there is no established relationships between the data unlike SQL-based relational databases. The JSON documents is flexible in the sense that it could store pretty much anything. I would like to mention that the synchronization may not only take place between PouchDB and a CouchDB database, but synchronization could also happen between multiple CouchDB databases.

This is a really good feature to consider for not only our current web application, but for other future and existing web applications that we have developed. But for the moment, I would just use PouchDB to store remote storage related information only, such as the protocol being used, the hostname of the remote storage service and the credentials to authorize access, all encoded as a URI. Then, when the user logs in or change their configured storage to use, the client would just send a HTTP request to a specific REST endpoint, so that the server could mount the correct remote filesystem for the given session.