Strategy - An Exercise in Development - Part 2

In any project such as this, creating or updating a website with no limitations (except perhaps financial), one of the juciest parts is choosing the tech stack. There are lots of reasons and justifications for why we'd pick one thing over another; and no doubt any choice made could be debated. In fact, having a strongly-held opinion about a particular technology is one of the attributes I most value in a developer - it means you care about what you're working with.

So, let's go through the choices I've made for this project, and some of the thought behind those choices.


The site is already on Node. I really like it as a platform for hosting web sites and services; I enjoy working with JavaScript; and there's already more than enough that's new and changing as part of this project, no need to pick something else here.


The site we're replacing uses , which is based off Express. I really like Sails, and would use it in the future, but I feel it obscures some of the lower-level aspects of using Node and Express. I so very briefly considered a switch to Koa or Hapi, but there's not enough of a reason for it not to wait for another project.


The first version of the site is running on MySQL, and it's worked quite well. The data model for the site is for now, and the foreseeable future, simple enough that any modern data storage solution would suffice. I'm picking Mongo as I've had little opportunity to work with it in the past. Also, picking the most popular NoSQL database is likely not a bad choice.


I definitely wanted to use this project as a springboard into single page applications. We've adopted Angular as the SPA framework of choice at my day job and while this was pretty much a coin-toss between Angular and React, I thought better than to try and master two front-end frameworks at once.

Amazon AWS was initially published on an instance of CentOS running Nginx. Hosting was procured from and has been a good experience. I'm going to continue running other sites and services there, but in the interest of staying up-to-date (the whole purpose of this exercise), we're moving to a cloud hosting provider.

I'll continue to do development on a Mac with the actual development server as a VMWare Fusion-hosted CentOS instance. I find developing full stack natively that eventually you run into a conflict.


We probably won't be utilizing Docker to its potential on a simple project like this, but I'm trying to define a set of best practices for myself as part of this and containerization definitely falls into that.


For CI/CD, I only considered three options: Jenkins, Circle CI, and Strider. I'm using Jenkins and Circle CI on other projects, and between those two I'd choose Jenkins, mostly based on cost and popularity. Of the CI/CD tools out there, the only one that caught my attention was Strider, as it's based on Node. I think I'll stick with Jenkins for the time being though.


Source control is not even up for debate, even though I'm the only one working on this project. Of all the source control sytems I've used, I actually like Mercurial the best, but Git is a close second and the clear frontrunner in the space.

I've been using for my personal repos up until now, but I'm using Github everywhere else, so let's use this opportunity to transition to that.


Like Mercurial and Git, I actually prefer Stylus over SCSS (or, at least I did last time I used both concurrently), but the other (SCSS in this case) is wildly more popular, and I use it on other projects.

The only reason I mention this here, and haven't explicitly called out other tech choices, like Webpack, et. al, is that I want to bring attention to using BEM. BEM stands for Block, Element, Modifier, and is a stylistic choice when writing CSS. The best explanation I've found is in [](MindBEMding – getting your head ’round BEM syntax). I've used it on another project, and definitely appreciate it.

Whew! There's a lot in this post, but I wanted to get my stack choices and rationale written down - this is more important than you think. How many times have you worked on a project long after decisions were made and can't remember why those choices were made in the first place? I'm sure there's lots to disagree with here, but I'm not trying to say these are the best, only the best for me on this project. Whether that means they're the best overall, really is up to the individual. Let's move on to some hands-on work.