Validating user JWTs

To make the most of this tutorial series,  create a Serverless Framework PRO account for free


In order for us to make an informed decision about a datastore for our application, let’s take a moment to consider the options available to us. If you have been a web developer for a while, you may be wondering why we don’t just use a relational database just like you would usually do for a web application you develop. Isn’t MySQL, Postgres or the like good enough to build a web application on? Well the simple answer is that the reason we have used those traditionally is because that was essentially the only available option at the time. Back in the late 90’s and early 2000’s, relational databases were one of the few options available to web developers. And at the time they were perfect for the situation; optimised for query flexibility in this new world of web development and reduced disk use by rather consuming CPU and executing joins on normalised data, since back then disk space was pretty expensive. And this “tradition” if you will has just continued to the present day because it seems like its “good enough”.

Times have changed however. We are no longer restricted by expensive disks, in fact CPU is now the more expensive of the two so we should rather prefer consuming disk over CPU where it makes sense, nor is web development all that new anymore; we pretty much understand what it is we need to do when we build applications for the web these days. This means that we can now consider all our options instead of just going what always seemed to just work, and instead we can make informed decisions about options that are better suited for our specific use case.

The advantage of having an application that is built using a Microservices architecture, and the fact that data sources preferably should not be accessible across our service boundaries, means that we can make sure we choose the right datastore specific to our services needs.

If we are building a service that needs to deal with transactional work loads with as low latency as possible in write and read and can handle a large volume, such as for a service that is primarily a REST API hooked up to browser client, a NoSQL database such as DynamoDB make sense.

For a service that needs the ability to perform ad hoc queries over a large collection of data at relatively low volume, such as a service that builds reports, a relational database such as an Aurora database on RDS, would be the ideal solution

The simple reason this distinction is great is that, while DynamoDB is a killer database for high volumes of traffic at very good speeds, it is pretty bad for any kind of activity that has ad hoc queries you don’t know ahead of time.

Ultimately what this means is that our choice of DynamoDB so far seems to be a good one. We are only concerned with transactional queries from our application so far, but we now know we have flexibility to look around and pick and choose between the huge number of datastores out there that serve different and often specific needs and choose the right one for our service.

Get updated when a new course is released