Preferred Technical Stack in 2020

Technology is moving as fast as ever. I try to keep up with developments post bleeding-edge phase as I’d rather tangle with being productive than with tooling, unstable interfaces and the like. I thought I’d take some time to put down what I currently prefer as a standard toolset for projects. This is for two reasons:

1. Hopefully others will find this helpful in some way
2. It will be interesting to look back on this post periodically to see how things change

Project type

There is clearly no one size fits all solution for software programming, so let me scope the project types I will be considering.

Server application: an application that resides on a server. This can be accessed through an API, or not accessed at all if it is a daemon or similar.

Web application: a web application that has no server component which resides in the user’s browser.

Three tier: an application that has a web component, connects to a back which in turn connects to a database.

Go To Toolset

I have a standard set of tools I move to use whenever a new project comes along, normally irrespective of size and scale. I find that the below tools almost always have enough capability to fulfil a project’s requirements, and as I am productive in them I can get moving quickly.

Go (server application)

Go is hands down my favourite programming language. When I picked it up over five years ago I fell in love with programming again. I view Go as a modern C-type language, where you have access to the bare metal capabilities of the machine with the niceties of more modern languages (some abstraction and garbage collection).

Go is super opinionated which makes having multiple developers on a project much easier (no arguing about code styles, certain patterns are specified by Go). This also makes it easier for you to focus on what you want to achieve, versus figuring out how the language wants you to do it.

Go is a compiled language. Compilation times are minimal, so much so that when I work on a project, the project compiles on every file write to check for build failures. A 500k lines of code project compiles on a 2015 Macbook Pro in under 2 seconds.

The performance of Go programs ranks at or near the top for various different tests. It’s normally at least on par with C++, and almost always faster than Python. The overhead of Go programs is minimal, much less than Java, which allows you to run a high-throughput system on tiny hardware.

I use go for any API application or server-based application, such as a process monitor or a stock notifier. When I’m making a small, quick application I will use the standard templating library, but for anything serious I put in a bit more work, expose an API and have a separate web frontend consume it. It makes the most sense for anything that you look to scale.

I could keep this list going for a while but the point is this: for every project that is server based, I always use Go as a starting point. No matter the size of the project, Go scales well and you are productive from day one. Try Go for yourself, you won’t regret it.

React (web application)

I’ve been using React on and off for a couple of years now and am really starting to enjoy it. Once you understand the project structure, and how to use Redux, everything becomes clear and easy. I love the way applications are designed in React, where components are split out of main entry points, there is loads of code re-use and state is beautifully managed using Redux.

While the javascript npm world has been maddeningly frustrating in the past, mainly due to dependencies of packages, this seems to be better these days especially with Yarn.

An added benefit of coding a web application in React is that there is an easier path to making your application mobile using React Native. The amount of code re-use between the web and mobile apps is really high and can save a boat load of time.

MySQL or PostgreSQL (database)

A lot of people hate on MySQL and my main argument for having it as my first choice is kind of lazy: I am most familiar with it and haven’t had any issues with it in the past. I’ve scaled applications to handle tons of load while being backed by MySQL - as long as the database is well designed, there isn’t a problem here for most applications. As far as which MySQL I use, I prefer MariaDB.

I’ve played around with PostgreSQL and will more than likely use this for my next project. It’s got a lot of cool features out of the box, and one of the things I’ve looked at during consulting work for a commercial bank was the replication feature which was pretty magic. Proponents of Postgres normally cite data types, scale, and enhanced features as the main reasons for switching.

Redis (caching)

Most of the applications I build have some sort of caching layer. This stores frequently accessed data like access tokens, or computationally heavy data like multi-tabled queries. Redis is a great tool for this, and the built in Time To Live feature you don’t have to worry about any clean up.

I don’t use a NoSQL database for any application that hints at having a relational data structure. I honestly don’t see the point most of the time: if your application moves to needing more complex data connection, you are blocked absolutely from doing this in a good way. If you need a long-lived key-value store you could just use Postgres or MySQL. But, for applications that you are sure you’ll only need key-value pairs, Redis is my go to.

Docker (infrastructure)

For any type of application I like to include a Docker file. This makes it easy to get the application up and running, if you’re sharing it or if you come back to it at a later stage, and also allows for easy testing and deployment. I’d normally use several Docker images during the development process, especially if this is a three tiered application. Having everything run locally and not be resource intensive is a game changer.

Kubernetes (infrastructure)

Depending on the application’s complexity, Kubernetes is my go to production deployment tool. I wouldn’t normally use Kubernetes for simple applications, but if I need something that is highly-available, scalable and can be easily managed Kubernetes is my tool of choice. It is available across cloud providers, you can test easily locally, it fits in to the above Docker workflow and one Kubernetes stack can run all of your applications.

On The Radar

There are several languages and frameworks that are on my list to learn or dabble with:

Swift. I’m very keen on getting a deeper understanding of building iOS native applications.

Meteor. I looked at Meteor many years ago and was very pleasantly surprised. The project has been going strong since then so I am keen on dabbling again.

Go. I know Go is at the top of this post, but I feel like there I have a lot more to learn about this language. I would prefer to learn more about how Go solves different problems, the language nuances, and get a deeper understanding of the internals before looking at another language.

Hopefully this list is not exhaustive of which languages I’ll be touching in the coming year. I’m also going to be reading books on software development to get a deeper understanding of approaches, patterns and systems.

I love software. The fact that you can design an application for some specific purpose in a way you see fit, by your own hand, makes me feel this craft is more art than science. No matter the focus of my work and how much I move to management roles, I’ll always want to get my hands dirty and build something, whatever that is. Being able to just do so is why I love software.