What do back-end developers do?

Backend development is all about working with data and returning that data to the clients.

That’s not the whole story, but this is where it begins.

The front end and back end are the key elements of any web-based system.

Simply put, the front end displays the raw data prepared by the backend in a structured, formatted, and interactive format.

Back-end developers do a range of tasks related to data and securing that data.

These tasks include but are not limited to building admin dashboards, CRUD interfaces, security mechanisms, APIs, third-party integrations, and a lot more.

Building CRUD interfaces

CRUD stands for Create, Read, Update, and Delete.

CRUD functionality exists in every data storage system, such as a file manager or a database.

For example, the Contacts app on your phone provides CRUD functionality to create, read, update and delete contacts.

Another example could be an online shop admin app.

Every online shop needs CRUD functionality to add new products.

It allows the sales team to update prices, list products, or even delete legacy data.

As a back-end developer, you might have a task to implement a CRUD system.

Making a CRUD interface is usually the first practice you do when learning back-end development, like a To-do app.

Making web APIs

We usually store data on a database and use that database as the single source of truth.

Our different applications – websites, mobile apps, and partners’ websites – use this single source of truth to receive and display data.

Modern applications don’t directly fetch data from the database. They usually request information from a web API instead.

Technically, a mobile app cannot access a remote database from a smartphone, but it can call a URL (web API endpoint) to fetch data.

When people talk about web APIs, they are usually talking about RESTful APIs.

REST (Representational State Transfer) is a set of standards for creating web APIs.

A web API made based on REST standards is called a RESTful API.

A RESTful API provides a set of URLs that enables consumers (another program) to access the system it represents.

Websites or mobile apps use RESTful APIs via those URLs, just like how we access a webpage.

Each API URL is called an endpoint, and each endpoint handles a particular action.

Here’s an example of an endpoint, which returns the list of products:

Yes, it’s a valid URL that you can open up in your browser.

Just like a web page.

However, instead of displaying a web page, it usually returns some unformatted – but structured – data.

API consumers are computer programs (mobile apps, web pages, smart-home smart-home firmware, etc.), and computer programs only understand structured data formats, such as JSON and XML.

Let’s make up a scenario.

Imagine you’re working as a back-end developer in an online retailer.

One day, the mobile team receives a request to create a campaign page where the goods on sale are listed.

The sales team has already added the products into the system using the CRUD functionality the back-end team has created before.

The mobile team creates the page with all the eye-catching visuals and functionalities.

However, to list the products on sale (when the user launches the app on their phone), they need to access the product information stored in the database.

How does a third-party system (your mobile app or even a partner’s website) access your database data?

Yes, RESTful APIs.

If there’s already an API with an endpoint to fetch the products list, then our mobile developers programmatically make an API request and get the lists of products.

End of the story.

However, if this particular endpoint doesn’t exist yet, the backend guys have to step in and create one.

Not all APIs should be available to the public, though.

Most of the time, API consumers need to be authenticated via a security layer because we don’t want everybody to access our inventory data (I’ll cover this concept in the next section).

So as a back-end developer, you’ll be creating APIs to exchange data with other systems, including but not limited to:

• Your API-centric front-end
• mobile apps
• Smart home appliances
• Partners website
• Any computer program, which needs your data

Building authentication and authorization systems

When you want to use the ATM, you have to authenticate with your PIN, or when you want to use your smartphone, you’ll have to unlock it first.

In every system, we need to protect sensitive data and functionality against unauthorized access.

Authentication verifies a user’s identity by validating an authentication factor, like a password, PIN, OTP (one-time-password), or an access token.

Photo by Pixabay (remixed) from Pexels

If the authentication verifies the user’s identity, but she is not authorized to access that resource, the system would deny her request.

This process is called authorization.

Authentication & authorization are not limited to humans, though. 

Computer programs also need to go through the authentication process to access a remote resource.

In the online shop example, the front-end code (program A) needs to authenticate as a program allowed to access the inventory data – provided by the backend-end API (program B).

Program A provides an access token with each request to the API as an authentication token.

These tokens come in the form of key pairs (e.g., APP ID and Secret key) or just a single key (e.g., API token).

API users usually receive these tokens from the API providers.

Sometimes this program-to-API authentication is done via an access control model, known as delegated authentication & authorization.

The most common delegated access model used today is oAuth2.0.

Please fear not, I’ll explain in a bit.

Have you signed up for a website with your Facebook or Google account? If yes, you have used oAuth.

For example, if you decide to use your Facebook account to make an account on Spotify, you’ll be redirected to Facebook’s website.

Then, you, as the resource owner, need to authorize Spotify to get access to your profile information, such as your name, email, and profile photo.

Once you authorize this operation, Facebook, as the authorization server, issues an access token and returns it to Spotify.

Next, Spotify sends another request to Facebook’s API along with the granted access token to get your information and sign you up automatically.

In the oAuth model, an access token is issued to a third-party system, by an authorization server, with the resource owner’s approval. 

The third-party system then uses this access token to access the protected resources.

So next time when you want to log in to Spotify, you can still use your Facebook account to log in. You’ll prove to Spotify that “you are who you say you are” by using your Facebook account.

The same goes with Google or any other platform on which you happen to have an account.

As a back-end developer, you might receive a request to implement such authentication/authorization workflows – just like how the back-end developers of Spotify did: Giving new users the option to sign up quickly with their existing account on another platform.

If you’re using a web framework, you won’t have to do everything from scratch because most frameworks provide authentication mechanisms out of the box – or at least through their standard libraries.

 Integration with external systems

Now that you know about web APIs, and authenticating to private APIs, let’s talk about a widely-used use case of system-to-system interactions: Integration with external systems.

Imagine your team uses an email marketing service like MailChimp for email marketing campaigns.

In this case, when users sign up to your website (confirming that they want to receive promotional emails), their email address has to be added to your MailChimp mailing list as well.

So the marketing team would be able to send out marketing emails from Mailchimp.

Adding the emails to a Mailchimp list one by one will get difficult at some point due to the volume.

It means the data entry process needs to be automated.

To do this, you’ll need to write a piece of code to automatically add new users’ emails to the MailChimp list via the MailChimp’s API.

It is an integration between your website and MailChimp.

And, of course, MailChimp will give you the access token you need to access their API.

All system-to-system integrations have the same concepts:

1. System A (e.g., Mailchimp) provides an API (usually protected by a layer of authentication)
2. System B (e.g., your website) sends a request to the API (with the access token) to send or receive data.

For example, the code snippet below is a minimalistic integration written in PHP, which automatically registers an email to a Mailchimp list. 

Imagine this piece of code gets called when a user registers on a website:

<?php
function subscribeToMailChimp($name, $email, $listId) {
    get_mailchimp()->post(“lists/{$listId}/members”, [
        ’email_address’ => $email,
        ‘status’        => ‘subscribed’,
        ‘merge_fields’  => [‘FNAME’ => $name]
    ]);
}

You don’t have to understand the code. It’s just to give you an idea of integration.

There are also tools like Zapier that offer plug-and-play integration solutions for many platforms – including MailChimp.

All you have to do is to set your Zapier integration to connect your system to the target system (e.g., MailChimp).

Zapier integrations are not free, though.

And that’s how independent systems exchange messages over the Internet.

Decoding a back-end developer job description

To give you an idea of how a back-end developer role looks like on job boards, let’s check out a piece of a real job description from LinkedIn:

Again, don’t mind the technical jargon. We’ll get to those in a bit.

Based on the above list, these are what you need to focus on when updating your resume for a back-end developer position.

1. You should be actively involved in the whole software development life cycle (SDLC), including requirement gathering, design, implementation, testing, deployment, documentation, and maintenance
2. You will be working with other teams such as front-end developers, QA engineers, content, marketing, etc
3. The technology stack varies from project to project, meaning you should be open to learning a new software stack that works best for a particular project
4. Adhering to the deployment schedule is an essential skill you need to acquire
5. Bring technical qualities to the team by using the best software engineering practices to develop robust, stable, and maintainable applications

Now, let’s see what skills you’ll need to land such a job.

Reza Lavarian Hey 👋 I'm a software engineer, an author, and an open-source contributor. I enjoy helping people (including myself) decode the complex side of technology. I share my findings on Twitter: @rezalavarian