Let's Build an API together - Part 10

Last Update: 02.01.2018. By Jens in API Series | APIs | Newsletter

Today, we are going to decide which data storage we will use. A few years ago, it was pretty clear to go with an RDBMS, but nowadays we have a few other options we can consider. If we have a choice at all. In the enterprise world, we are often restricted by some company policies or standards.

However, it is not a simple choice between SQL and NoSQL because there isn’t just one type of NoSQL. So, let’s explore a few options here.

• Key-Value stores like Redis. We only store some value, can be a JSON string, which is accessed by a single key. The are no relations between different entities at all.
• Document stores like MongoDB. We store our entity and all its relations in a single document and work only with the document, even when changing a sub-entity.
• Graph database like neoj4. Is usually used for storing relations and connections between multiple entities and for searching by connections.

There are more types, and you can find an overview on wikipedia. I’ll limit to these three types.

A key-value store could work in the basic version because we only have a single task entity. However, as soon as we add users and more kanban boards, we had to maintain the relations outside the DB in our code. Also searching or filtering tasks might require an additional search store if the key-value store itself does not support it.

A document store will not work as we do not store something that looks like a document. The nearest we could get is to handle a Kanban board as a document. However, this means, when we move a single task from one lane to another, we always had to update the whole document. Filtering tasks would become a job of the service layer and not on the database level anymore.

A graph DB is also not suited as we are not interested in multiple kinds of connections between entities. In maximum case, we have a relation between the user and his kanban boards and between a board and the tasks on it. Doesn’t make sense to me.

Leaves us with the old school choice of a SQL database. It’s perfectly suited for our simple relations and searching, and filtering are easy to be done on the database level.

Takeaway:

Before you choose a database type, evaluate if it fits for your use cases. Don’t use a DB just because it is hip.

I’ll continue with SQL, but you are welcomed to choose another one. If you do so, please share it with me, I’m interested in how it works out.