Have you ever noticed how there are no awards for backend development? Sure, there are “web” awards, but they mostly focus on design and the visual aspects (e.g. Awwwards, the Webby Awards). Mobile has many awards such as the Mobile Industry Awards, even HR receives awards (the HR Excellence Awards).

No awards for backend, though. It’s as if the world thinks that what we do is easy and we don’t need any special knowledge or skills to write backend applications.

It is a job that nobody notices when it’s done right, but when it’s not, everything crumbles. Sort of like the Night Watch in Game of Thrones. If you are interested in pursuing this not very glamorous, but badass role, read on to find out what it entails.

There are a multitude of programming languages available for backend development. Most of them have more than one framework for building a web application. From Ruby’s Ruby on Rails and Python’s Django to C#’s ASP.NET and Java’s Spring, the list goes on and on. Sorry if I didn’t mention your favorite framework, this of course barely scratches the surface.

If you’re only starting out, it’s best to choose a programming language you are most familiar with because all frameworks work in a similar fashion, some with more and some with less magic in them. However, they all have one thing in common – they have to work within the confines of the web’s request/response infrastructure.

The state of your application will need to be stored for long-term storage and retrieval. For that, you will need some kind of a database. You can use a relational database like MySql or Postgresql or a NOSQL like MongoDB or Redis, depending on the application’s needs.

In my experience, we opt for a relational database 90 percent of the time because we end up needing the relational connections.

It’s possible to use other types of databases, too, such as the Graph database or the database for event sourcing.

With the basic tools for building a web application covered, you need to figure out what kind of architecture you are going to use. The two currently prevailing architectures are Monolithic and Microservices.

In a monolithic architecture, all the application’s functionality is coded in one big repository. Whenever you make a change you can potentially bring down the whole application, but the changes themselves are easier to make.

On the other hand, a microservices application is broken down into multiple smaller services that (should) work independently of one another. Changes in one service won’t affect other services, but keeping them all in sync becomes a problem once they start to stack up.

At some point, your application will need to respond to requests coming from the world wide web. You need to decide how it will respond, with an outdated XML or a JSON.

When you use JSON for your response schema, you will need to structure it so that all the responses follow the same structure. Whether you choose GraphQL, JSON:API spec or another schema, is completely up to you. There is no correct answer here as long as you respond with JSON. It might be smart to learn what a json schema is, too.

Since you want your application to be accessible to the whole Internet, you need to deploy it somewhere. There are plenty of options, from buying your own barebone machine you can customize and take care of, through paid services like AWS or Digital Ocean, which maintain the hardware for you, to SaaS services like Heroku where you can deploy an application in one command line.

I should probably note that you will also need to learn about Kubernetes and Docker if you want your application to scale well. However, we’ll leave these for now as they’re a topic for a separate blog post.

An admin dashboard is a good way for you to create and edit your content. To build one, though, you will need to learn some frontend languages – HTML, CSS and some Javascript. Fortunately, there are complete frameworks like Bootstrap that will help you build the pages, but you still need to understand how they work in harmony.

At one point, some of the requests will just take too long and users will start complaining. For example, those where you resize uploaded images or export a portion of your data. These types of requests can be migrated to background jobs so that they exit early. Users don’t have to wait for a response and the application responds asynchronously.

You will need to learn about queues and lambdas.

Emails should also be sent in the background, but designing them is a whole other beast to master. I recommend just going with the simplest design you can think of.

You want your application to be available all the time. To achieve this, you need to learn about metrics and how to read graphs to figure out which part of your application is slow. Reading application logs is a science in itself, but yet another one you need to tackle. You will also need to learn how to set up alerts when your application goes offline so you can quickly restart it.

The challenges you’ll face on your backend journey don’t end here. You might find yourself working with third party API’s. I can’t begin to explain my frustration with those. Responding with XML, responding with the wrong HTTP status codes, or just plain not working as the documentation states, it’s just always bad.

Next, there is this pressure of achieving 99.999% availability, which is nearly impossible in practice.

It’s difficult to build a backend “portfolio” because backend is not “showy” or “pretty”. Backend applications don’t win awards. Still, I wouldn’t give up backend development for anything.

First, it’s so much easier to test backend applications than Javascript or mobile apps. Next, you absolutely don’t care or have to worry about what browser the end user is using, and finally, you don’t need to know the latest and “best ever” javascript framework that seems to come out every three months. You also don’t need to make fun of Javascript, that’s purely optional.

Backend is the backbone of the web. The sword in the darkness. Give your backend developer friend a high five when you see them.