My tech stack if I had to build an app today
Tags: webdev, node, javascript, go
Published: 2017-01-03 20:40:28

---
title: My tech stack if I had to build an app today
published: true
description: My opinion on which state-of-the-art technology stack to pick for a modern web app
cover_image: http://i.imgur.com/DxEPloI.png
tags: webdev, nodejs, javascript, golang
---

What technology stack would I choose, if I had to develop a web application completely from scratch? That's the question this article will cover.

First of all: by saying web application I'm referring to something between a plain static HTML page and an entire Facebook. Basically, an application that fulfills a certain domain of tasks for the user and that requires the usual features like user management, a backend database, multiple UI views and controls, etc. The size of application I'm thinking of could be a browser-based chat app, password-manager or something similar. Neither too simple, nor too complex.

Back to the topic. Choosing the right technology for a web app feels much like customizing a new PC or even a new car. There are nearly endless options to be weighed to finally pick a bunch of them for a new web application. This super famous article [How it feels to learn JavaScript in 2016](https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.m1nodqu6f) complains about the confusing and ever-growing, chaotic jungle of new JavaScript frameworks in an ironical way. Indeed, I hear similar arguments from many developers these days. Many of them claim that code quality was getting worse in the web and that every newbie JavaScript programmer threw out his own new framework on yet another .io domain. Although that might be true to a certain extent, I personally still like the great technological variety and innovation. I love to browse GitHub, Reddit, Hackernews and Co. to discover new cool libraries to try out in a project some day. And here's what I would pick if I had to realize such a project right today and if there weren't any restrictions. 

Of course, the technology choice depends on the concrete project requirements to a certain extent, but not completely. Consequently, a new project is always a chance to try something new. ThoughtWorks just published their new [technology radar for 2016](https://www.thoughtworks.com/de/radar), where they separate into categories _adopt_, _trial_, _assess_ and _hold_. Of course, _hold_-techs are not an option for new projects and I actually pretty much agree with their views on what has to be in the _hold_ category. _Adopt_ basically are things that are modern, but also well-established enough to avoid too much risk. _Trial_-techs are more experimental and _assess_ are the latest fancy s***, so to say. Since I'm extremely eager to try out new things, my stack would probably mostly consist of technologies from the last category. So what would my stack now look like? Actually, I couldn't decide on one stack, but set up two: _the fancy one_ and _the super fancy one_. Additionally, I define their intersection as _the base stack_, which consists of fundamental tools etc. that both have in common.

### The base stack
First of all, I'd use __Git__ for version control, __Visual Studio Code__ as code editor and __GitLab__ for repository hosting and as build server. If I didn't had to implement user management myself, I'd pick __Auth0__ for that. For deployment, I'd use containers with __Docker__ on __DigitalOcean__ machines and if I needed multiple instances, __Rancher__ would help me to manage them. As reverse proxy in front of the backend I'd choose __nginx__ since it's extremely efficient, performant and has __HTTP/2.0__ support. For bundling, __Webpack__ would be my choice and task automation would be done using plain __npm scripts__. For styling the UI, I'd simply use __Bootstrap 4__ and __SCSS__.  

### The super fancy stack
The key point here is that I'd want to abandon a traditional REST API in my project and use __GraphQL__ instead. The backend would be written in __NodeJS__ with [__Graffiti__](https://github.com/RisingStack/graffiti) as GraphQL implementation. I don't know much about the latter one, yet, except for that it's the de-facto GraphQL solution for Node. Why Node? Because it's simply the best choice for the web (my view...). It's performant, comfortable to develop and especially brings consistency by having JS in front- and backend. By always being quite up-to-date with the latest ES* features, Node doesn't get boring. Since GraphQL is told to work best with other Facebook technology, I'd not be that experimental here and build the frontend on __React__ plus __Relay__ (which is still completely new for me). Database would probably be a __MongoDB__ (JSON everywhere!) with [__Waterline__](https://github.com/balderdashy/waterline) ORM. To put a cherry on the cake, I'd also introduce __Redux__ in addition. I haven't worked with it much, yet, and I heard that it's kind of mind-blowing in the beginning. However, I consider its concept to cover a large potential to manage consistency in my app. The last thing here is that I desperately want is ES6 syntax. It isn't supported by the React compiler afaik (please correct me, if I'm wrong), so I'd use __Babel__ to have latest JavaScript features. If having to go mobile, __React Native__ would be the rational choice.

### The fancy stack
This stack differs from the _super fancy stack_ in a few points. A key point is that it would not use GraphQL, but a good old REST API. This API would be written in __Go__, since I like the language - especially its efficiency and its good suitability for web development. More precisely, I'd use the [__Iris__](http://iris-go.com/) framework. I've read the documentation and it looked incredibly powerful to me (in terms of both functionality and perfomance) _(__EDIT__: It's not what it seems! Please see my comment below!)_. For the frontend I'm balancing between __Angular 2__ and [__Aurelia__](http://aurelia.io/). Angular 2 is guaranteed to work for any potential case, is extremely powerful and has great community- and library support. However, Aurelia look promising, too, and probably is even more clear and less boilerplate code. Consequently, I'd give it a try. But if having to go mobile, I'd still favor Angular 2, since it perfectly aligns with __Ionic 2__.

Two other options, which look really interesting to me are __Meteor__ and __HorizonJS__. However, I'm not sure, if it's a good idea to commit to only one comprehensive framework through the full stack.

So these are my two alternative ways through the webdev jungle - btw, [this good article](https://medium.freecodecamp.com/a-study-plan-to-cure-javascript-fatigue-8ad3a54f2eb1#.3ri3a1fdv) describes another one, especially for newcomer web developers. Sorry, that I haven't justified all choices. Actually, as you probably know, if you're a developer, subjective views like these often aren't even based on pure rational considerations, but are rather emotional and spontaneous.

Please feel free to give me feedback on my tech stack of choice! 

__EDIT:__ Another framework I'd really like to try out is [InfernoJS](https://infernojs.org/), because it claims to be extremely lightweight and performant. However, before using Inferno, one should probably be familiar with React, since it uses very similar concepts and syntaxes.

__EDIT 2:__ After having read [this article](http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html) and having done some further research on the Iris framework I really have to retract my above statement that I'd use it as a web backend. While it looks nice on paper, after diving a little deeper I really have to admit that it'd be morally tenable to support the authors of that project. So please forget about Iris and take a look at [Beego](https://beego.me/) instead.