Back to the Backend Era
Part 3 — The Database and the Rest
In this series of articles we explore not what we can do with serverless application platforms, but what we no longer have to do.
In Part 1 we chose a platform and operating system, and in Part 2 we chose the programming language and runtime environment for our backend.
This time, we will choose a database and the rest of our technology stack.
How to choose a database? First we need to consider whether we want a relational database, an object store, a graph database, a key-value store, whether we need an in-memory database or not, if we need ACID properties, what horizontal or vertical scalability we will need, what types of clustering, backups, fail-over mechanisms, performance requirements, licensing, security models, support of specific data types, operating systems support, etc. We might carefully evaluate PostgreSQL, Oracle, MongoDB, Redis, CouchDB, RethinkDB, Neo4j, Hadoop, MySQL and Microsoft SQL Server, taking into account all technological aspects and consequences, as well as the job market — again — and let’s say that we choose Mongo, for the sake of simplicity.
Now, we have a Linux KVM VPS with Ubuntu, Node, Express and Mongo. As soon as we choose a preferred way to integrate Node with Mongo — which can be mongodb, mongodb-core, mongojs or mongoose, among others — then we are actually pretty close to finally thinking about our application. Meanwhile, of course, we have to install Mongo on our server and immediately start thinking what to do when our data outgrows a single VPS instance, or when we need to have it distributed geographically. But that is a problem that we can easily pretend doesn’t exist — at least not yet — so let’s say we happily ignore any frightening thoughts about database clusters and replicas, caching, syncing and load balancing.
Every “let’s say” in that reasoning is like a new stack frame, like another level of recursion. We need to choose something but there is often no obvious reason why we should choose this and not something else. And yet, every choice and every decision is built on top of the previous one, building a tower that is more likely to collapse with every new step and that needs more and more research to support its weight.
But at least we can now write our first line of code. It seems like we have our technology stack finalized and we can do some programming.
We are writing a backend but we are not in the nineties, so our backend will not render HTML simply to throw it all out every time a user clicks anything, just to send him a new HTML half a second later, CGI-style. We are writing a modern single-page application that will have accompanying native mobile apps in the future for at least 3 different platforms, so our backend will not output HTML but JSON or XML. Let’s say that we choose JSON and it will be a RESTful web service. Another “let’s say”. It could be using XML-RPC or SOAP instead of REST, but having carefully considered (again) all technical and work-market related pros and cons, we choose REST.
So, where are we? We decided that on our Linux KVM VPS we’ll run Mongo, Node and Express on Ubuntu to implement a RESTful API serving JSON data. Every word in that sentence has costed us so much research and energy that we never want to revisit it ever again. From now on, we will experience a brief panic attack every time we hear someone asking “Hey, why not MySQL, Ruby and Rails on Fedora with SOAP and XML on a Xen VPS?” But, we chose our technology stack, and we put so much time and energy into it that anyone questioning any single piece of it clearly must be insane and not worth listening to.
We should be very happy right now because we have made the most important decisions. We can now install all the software that we have chosen, which we’ll do in Part 4.
