Building Blocks of a Modern Web Application
Achieving velocity 🏎 and getting things done ☑️ by choosing your stack of back end 🛢 and front end 🖥 technologies wisely.
Having a product idea is good and fine, but getting a service online requires more than ideation and inspiration. In the following sections, we will outline which technologies in general are necessary to build a web application and deploy it reliably. Based on the general requirements, we will also highlight which tools and frameworks we have chosen to achieve a streamlined, highly automated workflow.
Basic layers of a web application stack 🍰
Let us start with an overview of the different aspects of an online service. It might depend on your background on where you start within the stack, to me the back end is the foundation for everything else.
Without a back end, or at least some API or database layer, it is hard to build anything. Typically, you choose a programming language and maybe a framework to work with. On top of that, you will need some application server to run your code in. And as a last component in this basic layer, you also most likely want to throw in a web server that connects your application server to the internet and delivers your online service.
For scalability, you might want to deploy your web servers and application servers behind a load balancer, but at this point we will not go into further detail.
The next layer on top of the API is the front end — which is what your users will see and interact with. Today, many modern applications are quite heavy on the front end with a lot of HTML and CSS, with JavaScript playing an ever more important role to tie it all together and support responsive user interactions.
The final layer we would like to highlight is the Ops in DevOps. To tie back and front end reliably together and make it all available to a global, or any, audience, you need to deploy your components.
Small web startups tend to leverage developer-friendly, highly automated cloud environments like AWS Elastic Beanstalk on Amazon Web Services, Heroku, Google App Engine on Google Cloud Platform or App Service on Microsoft Azure. While running on public cloud at scale can be expensive, starting on public cloud helps focusing on the application itself without getting caught up in all the nitty-gritty complexities of operating an online service.
In this article, we will focus on the back end and front end technologies. In another article, we will dive deeper into cloud solutions, and give some insights into configuration and deployment.
Foundation layer: data and logic 🛢
In the early years of the world wide web, I used to write web applications in PHP, mainly version 4, later also version 5, with a MySQL database. Building on the so called LAMP stack was pretty common in the late nineties and early 2000s — and it still is a widely-used platform until this very day.
However, when I studied computer science as part of my degree at Karlsruhe Institute of Technology and Royal Institute of Technology in Stockholm, I started to understand many concepts of software development and programming languages better, and came to the conclusion that PHP with all its quirks back then was just not a language I would like to work with in the future. So I looked for other options. At that time, Ruby on Rails 🛤, or short RoR was becoming immensely popular, powering much of the up and coming Web 2.0 services.
While Ruby on Rails would have been a sensible option, and some tools I use daily like GitLab are built with Ruby on Rails, I felt that the RoR crowd was just a bit too cool and hip for me. That might be also reason why I live in quiet, leafy West London, and not in edgy Shoreditch.
Jumping on the cloud train early 🚝, I also began looking at Google App Engine, then a pretty new cloud Platform as a Service that supported a little web framework called web.py based on the Python programming language 🐍. I liked Python, and soon started deploying one, two tiny side projects on Google App Engine. I quickly began toying around with a more powerful framework that offered more convenience features: Django 🦄.
Since PostgreSQL 🐘 seemed to be the preferred database among Django developers, I decided to also switch from MySQL to PostgreSQL — after all, both are relational databases that support the standardised SQL query language, so from a developer perspective, it was not a big change. Like PHP, early MySQL had some annoyances and shortcomings, and while they were not relevant for what I was building, I felt that over the long run, PostgreSQL might be the better option.
Now is 2017 📆, and despite there being a huge selection of frameworks available in a wide range of programming languages, I still decided to use Python and Django for UnscrewMe. I must admit, I did not really consider for a second to use Node.js or go all-in with a serverless application. This was not because it would not be at least as reasonable or good, but simply because my interest in UnscrewMe lies more in the product 💡, than in the technology ⚙️.
Over the past four years or so, I have led the development and day-to-day operations 💻 of two Django applications, so it was just natural to stick to what I know and get on with the job ☑️, instead of jumping into an unknown language and framework ❓.
Django might not be the latest and coolest thing out there, but it is a very mature framework with a lot of good documentation, extensions and help available 👍🏻. There are many aspects, where it makes sense to build on existing solutions and not reinvent the wheel. The large Django ecosystem does help us focus on what is important and leverage standard functionality, either from the core framework or from additional packages that extend the main functionality.
Interaction layer: shiny and moving 🎈
While the back-end technology was an easy decision, selecting a front-end framework was a bigger challenge. To my disadvantage, the web has moved on rapidly 🎢 while I was busy studying 🎓, discovering Stockholm 🇸🇪, drinking wine 🍷 and moving to London 🇬🇧. This meant that the web in 2017 is very different, especially on the front end, from how it was ten, 15 years ago.
While I could get away relying on more traditional front-end development for my past and current projects, for UnscrewMe I wanted to use state-of-the-art tools and frameworks from the beginning. As a result, I had to learn something new, and had to choose between different options to get started.
I wanted to pick up something common, and nothing too niche. Ed, a good friend and colleague, is a big fan of Elm — for me, the slight obscurity and non-measurable market share of Elm ruled it out right from the beginning.
Reading around and asking web developer friends, it boiled down to three options:
- React, “A JavaScript library for building user interfaces”, backed by Facebook.
- Angular, “One framework. Mobile & desktop.”, backed by Google.
- Vue.js, “The Progressive JavaScript Framework”, developed by Evan You, who worked at Google and at Meteor— kind of the underdog compared to the other two.
With only basic experience in JavaScript and a strong dislike for the syntax, I wanted to go with a framework that is simple to understand and easy to use. Given the might and complexity of React and Angular, I decided to go with Vue.js.
It is perhaps not be the best choice for large applications, but it looked like the one that I might enjoy working with most and which offered a more gentle learning curve, helping me to get my product implemented faster 🏁. Hopefully.
In this context, I found an interview with Evan You interesting, where he described his motivation behind Vue.js:
[…] just extract the part that I really liked about Angular and build something really lightweight without all the extra concepts involved […]
Compared to React, Vue puts a bit more focus on approachability. Making sure people who know basics such as: HTML, JavaScript, and CSS can pick it up as fast as possible.
(Vivian Cromwell: Between the Wires interview with Evan You, 3 Nov 2016 — our emphasis🖍.)
My old pixel pusher pal 🖱 and UX friend Dirk (Dirk Schürjohann on Medium) from DECAF ☕️ recommended a great, brand new Vue.js book 📗 to me: ‘The Majesty of Vue.js 2’. I quickly bought it and read it from start to end. I found it very accessible and engaging with simple examples that help understand basic concepts. After finishing the book, I built a first, basic proof of concept — a simple list of events, using the dynamic and templating features of Vue.js. I will go into more details about learning Vue.js in another article.
Having decided which JavaScript framework should be the foundation for all interaction, the next step was to specify which front-end CSS and design framework 🎨 we wanted to build on.
I gained some experience in Bootstrap and really wanted to use it for UnscrewMe — I’ve also used it for the pre-launch page. But as I made myself more familiar with Vue.js, it became obvious that Bootstrap, building on the tried and tested, and increasingly unnecessary, jQuery was not the best match for Vue.js. Some work would be needed anyway to marry the two worlds together. And basic Bootstrap missed one control we will really need quite soon, a calendar widget. There are solutions, but having worked with perhaps the most popular one, I wasn’t fully convinced.
So I looked for other options, better integrated with Vue.js. After Material Design, a concept popularised by Google, is all the rage for mobile applications, and mobile 📱 is a must in 2017, I looked at two or three packages and settled on Vuetify as the library of choice.
Aiming for velocity 🏎
It is unavoidable to learn new things and it is good to employ modern technologies and tools, but it is crucial to strike the right balance ⚖️. Especially at the beginning, the best tool is the one that gets the job done quickly ⏱.
Not every tool is suited for every task, and every decision might have its limitations. Looking ahead is smart, looking ahead too far could slow down progress and turn out as a bigger failure than having to refactor parts of your product later, when it is actually necessary.
Taking over where this articles ends, we will soon go into more detail about our learning experience in getting started with the JavaScript framework Vue.js. But first we will give some insight into our writing process in the next article.
(Quite surprisingly, I did not know about this place until recently. While it is basically just a knock-off of any Streat Feast location, Mercato Metropolitano is still a pretty decent night food market. At the excellent Pastalab I got two tasters, and went with the red, a lovely, fruity yet well-balanced “12 e mezzo" made from Negroamaro grapes grown in the Salento IGP region in the very South of Italy by winemaker Varvaglione. It has a certain depth and was matching the cheesy pasta with black pepper beautifully, it could even take up a stronger blue cheese.
While editing this article, I am still full from an amazing truffle pasta dinner at the outstanding Quirinale — of all the wine we had there, the 2015 “Patricia” Pinot Noir from Alto Adige DOC in Italy by winemaker Cantina Girlan was my favourite.)
