A Brief Introduction to Document-Based NoSQL Databases

Firestore is a document-based NoSQL database, and in order to properly understand how to use it we will need to cover some basic concepts. Our use of the database will be rather simple, so it is not critical that you have a thorough understanding of how a document-based database works, but it will certainly help to understand at least a little.

Before we get into specifically discussing “document” databases, I think it is useful to quickly cover some other types of NoSQL databases (which basically covers anything that is not a typical “relational” style database like MySQL). Some types of NoSQL databases include:

• Key-Value (redis, Amazon DynamoDB, memcached)
• Columnar / BigTable (HBase, Cassandra, Amazon SimpleDB)
• Document (Firestore, CouchDB, MongoDB, Riak)
• Graph (Neo4J, AllegroGraph, InfoGrid)

Two commonly used NoSQL database structures are Key-Value and Document (like the Firestore database we will be using). Key-Value and Document-based databases are both very similar in nature, but there are differences.

A Key-Value database is a simple way to store values indexed by a key. You would already be familiar with this concept if you have used the browser’s local storage to store data. To use the browser’s local storage as an example, you would set a value on a key like this:

localStorage.setItem('name', 'Josh');

and then you could later retrieve the value by using the key like this:

localStorage.getItem('name');

A document database is similar but stores its information in a structure that closely resembles JavaScript objects or JSON strings. These “objects” that are stored are referred to as documents. I think this terminology is quite confusing because when you think of a “document database” you would probably be thinking in the context of documents like a word document or spreadsheet. This isn’t the case though, a document in this context is simply a JSON object like this:

{
    "id": 1,
    "name": 'Josh',
    "country": 'Australia',
    "interests": ['Angular', 'RxJS', 'Signals']
}

The reason these are referred to as “documents” is because a document generally contains all the information you need in one place. If I look at an invoice, I could see all the data I need right there: biller, items, subtotal, tax, and so on. In a document based NoSQL database this might look like this:

{
    "id": 392,
    "biller": 'Bob\'s Building Supplies',
    "items": ['bricks', 'paint', 'wrench'],
    "subtotal": 230.32,
    "tax": 0
}

In a relational database, this information might be split up across multiple tables (not all in one place like a “document”).

You could also store a similar JSON object as a value in a Key-value database and then retrieve that entire JSON object later. So, what’s the difference between the two approaches? The difference is that with a document database the database knows about the structure of that JSON object, and provides a means to query against it, rather than just directly accessing a specific key value. If the above was just a chunk of data we needed to retrieve we could easily store it in a Key-value database, but if we wanted to run a query to return objects where the country was Australia, then it would be better to use a document-based database.

This is a very brief introduction to the concept of a document-based database, and if you don’t have any other experience with them you will likely need to do some additional learning to be able to build your own databases. Fortunately, our requirements for this application are quite simple and involve just storing a single collection of documents called messages.