In this post I’m going to cover the Tech Stack I chose as a back-end for my app, TrainingWall.
When starting a new project, commercial or personal, I’m always presented with the question:
What tech stack do I use for this?
Sometimes it’s a very simple and easy question to answer, ”What you know best” other times it can be a real challenge and the initial investment in architectural planning can put me off a project.
To answer this question I looked at the outcomes I want my backend to deliver.
- REST API - Could easily, and probably will in the future, add a GraphQL layer.
- Automated testing
- Connects to a database
That’s a very generic and rather rudimentary set of requirements right? But it gives a good start and besides, every app should be test-able!
NodeJS is a very well supported platform with an incredible number of open source packages, everything from indenting your code to machine learning libraries. This incredible eco-system leaves you with a wealth of packages to choose from that can do pretty much anything, certainly an overwhelming quantity for any newbie. I chose to stick with v8.13.^ at the time of writing due to package support.
Is it important to choose a long term support (LTS) version?
Support for NodeJS is similar to that of Linux, a distribution or release version is chosen, and scheduled, for long term support and it therefore receives long term support for packages included with the release version and larger packages tend to stick with this support cycle. I say tend to as some packages aren’t as well maintained as others. Keep in mind that a lot of packages are maintained by the community, people like you and I, just more generous!
Now that I’ve chosen NodeJS, why did I choose ExpressJS over, say, Koa?
We have a server technology, and a set of HTTP utilities, why MongoDB?
One of the biggest advantages I’ve found when using MongoDB and Atlas has got to be the incredible speed with which you can create schemas and adapt them to any use case, even halfway through development.
I put a large value on this factor when I’m building a prototype, schemas are likely to evolve during development, they’re also very likely to evolve once the first version releases to production! It takes a while to stabilise a database schema when you’re one man. Nobody is faultless, we all overlook things.
Atlas has a very good free tier that enables you to get up and running with a development and production database without any hassle.
Creating schemas for a “schema-less database” seems odd, but it isn’t. It’s normal to want structure, that’s what a database is after all, a bunch of data points organised in a query-able and predictable manner.
I’ve worked with two different frameworks that apply schemas to MongoDB databases, Mongoose and LoopBack. LoopBack is very opinionated in database and endpoint structuring that I wanted, it would’ve been a fine fit and the useful CLI tools would’ve made for faster development. LoopBack is also built upon both Mongoose and ExpressJS, so I chose to work with the building blocks and apply my own opinions.
This leaves the testing framework
Mocha is a very simple to read testing framework and has a variety of different extensions but most of all, it’s my favourite coffee related drink. The little things.
To clarify, I’m not a fan of Chai in my coffee but I’m more than happy to use it for HTTP testing!