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.
Node.js
The storesdowntown.com 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.
Express
The site we're replacing uses https://sailsjs.com/ , 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.
MongoDB
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.
React
I definitely wanted to use this project as a springboard into single page applications with a focus on SEO. 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'm going to try and expand my horizons even further with this project and see on which side of the coin I'd prefer to be on.
Amazon AWS
storesdowntown.com was initially published on an instance of CentOS running Nginx. Hosting was procured from https://openvirtuals.com/ 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.
Docker
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.
Jenkins
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.
Github
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 http://repositoryhosting.com/ for my personal repos up until now, but I'm using Github everywhere else, so let's use this opportunity to transition to that.
SCSS and BEM
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 [https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/](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.