Back to the Backend Era
Part 2 — The Programming Language
In Part 1, we talked about the hardware platform and the operating system of our backend.
This time, we will choose a programming language and the runtime environment.
We were thinking about Python, Ruby, Perl, Java, C#, PHP, Node, Go, Lua and Clojure, and we finally chose Node.js. This decision appeared to be easy because we have most experience with Node, so starting a simple backend in Node seemed like a natural choice. But is the relative experience of the first developer who happens to think about the project really a good reason to choose one language over another? Are there more important issues to consider?
This is actually a pretty big deal; it’s the most important decision we make. Even if switching an operating system or Linux distribution may seem possible, if we ever decide to change a programming language it will mean rewriting the entire application — which will almost certainly never be done in practice. This project will most likely get stuck in this environment forever, so we need to choose wisely. There is a reason why so many projects use Python 2, even though Python 3 has been available for years. If upgrading just a version of one language is so problematic, then you can imagine how hard it would be to switch to an entirely different language and runtime environment.
Choosing a language for backend code is important not only because it is almost impossible to change later, but also because every language has different strengths and weaknesses. There is no language that will always be the best. It all depends on the requirements, which are not known at this point — you can never anticipate what new feature will be requested a month from now, let alone next year. However, every language is different not only in respect to its syntax, semantics, its philosophy regarding concurrency, or built-in functionality. Every language is also an ecosystem of third-party modules and a supporting community. Additionally, it is a market of potential developers that can be hired for the project, and recruitment in the IT industry is not getting any easier. Everything suggests that it will only get worse.
I want to stress once again that a simple sentence, “Let’s say we choose Node.js”, is actually a research project on its own, with strategic decisions and serious consequences spanning from the quality of the module ecosystem to the situation on the international job market. But let’s say that, having considered all that, we indeed choose Node.js.
So, Node it is. Can we start writing the backend now? Of course, as soon as we choose the Web application framework that is best for us. In Node we have Express, Hapi, Koa, Sails, LoopBack, Restify, and many more. After we read all of the “Top 40 Node Web Frameworks” articles and carefully evaluate all their pros and cons — again considering the technical merits, the likelihood of getting updates on time, our desired abstraction level, our prefered opinionatedness (if that is even a word, because most framework authors and users put the most emphasis on how opinionated their tool is), and the ease of getting developers hired or trained — and, after having considered all that, let’s say we choose Express.
At this point, we can start writing some backend code — as soon as we choose a database… Which we’ll do in Part 3.
