What it means to be a backend developer

What it means to be a backend developer

I see more and more flame wars on twitter regarding front VS back- and who's stack is the most complex.
Not only does it annoy me beyond reason due do it's inherent pointlessness, it also pains me to see how backend is perceived at large.

Ignorance is thinking that you have it the hardest, or that a whole stack can be boiled down to a single pattern.

If not CRUD, then what is backend ?

Here's my definition:

Backend is the management and enforcement of business rules, security and data at scale.

Let's break it down.

Management and enforcement of business rules

Businesses evolve, sometimes faster than code is able to follow. Models and patterns that made sense a year ago may be completely irrelevant now. 

Beyond that, you may want to segment your business rules based on regionality, A/B testing, client type (browser, mobile app, etc) and even network type.
The clients of backend teams are front-ends. They will dictate the interface and how data should be transferred. Thus, efficient transactions are tied to the domain, and not atomic data models. For example: The landing page for an app may require user data, preferences, a bit of model A and some of model B. 

This is why I hate CRUD.

Within CRUD, you'd need to make 4 calls, which would return a whole lot of information that you don't need. Whereas GraphQL, JSON-API and others promote domain-oriented designs and can deliver all of the required data- and no more- in a single request. The result of which is faster end-user experience, simpler front-end code and cheaper AWS bills.

Why do we do it in the first place ? Because it's quick. Some frameworks allow you to setup a whole API in a simple command, and then scaffold new sets or routes automatically.

While it might be very compelling for small projects, tying something that is ever-evolving and highly faceted (business logic) to something that is meant to be rigid (database schemas) will yield some pain in the long run.


I am by no means a security expert, nor do I expect other backend engineers to be. Yet an important part of the role is risk mitigation.

The points I usually look for are:

- Authentication
- Authorisation (yes, it's different)
- API surface
- Software vulnerabilities
- Common attacks (impersonation, MITM, XSS, SQL injections, etc)
- Audit trails
- Rule of least privilege
- Robots / crawlers

While most of the network-related security topics are delegated to devops teams, like DDoS, rate-limiting, IP banning, etc- it's important to note that this is done in conjunction with the backend team in terms of either detecting, implementing or monitoring.

A crucial skill of backend developers is the ability to troubleshoot issues and coordinate response teams, formulate attack plans and implement durable solutions. This implies robust knowledge of the infrastructure, architecture, data models and finding points of contacts.

Once again I'm disappointed by CRUD. Because business logic for a given product features may be spread across many models, it limits our ability to track if a request has met all requirements before performing changes to the database or that changes happen predictably and understandably (looking at you FeathersJS).

What's worse, some frameworks automatically generate routes from your database models, route that you may not want that that you have exposed(API surface). A secure API only exposes the endpoints that you explicitly want to.

Data at scale

A good backend developer should know databases. What's the difference between redis, mongo, postgres, etc. When to chose one over another, what the tradeoffs are, how much nodes should it replicate to, what are the hardware requirements, how many nodes do we need for the traffic.

Then, there's data modeling, how to define schemas that will resist time and scale. What are the access patterns, what fields might be added in the future, is there a schema migration protocol in place.

Cache is data too, where should certain entities or responses be cached, what's the eviction strategy, has governance been established, can we measure our hit ratio ?

Finally, APM monitoring data is also critical, how are our APIs working, are we meeting our SLAs, are we noticing suspect traffic, is a service down ?

To recap, this is how I see the role of a backend, and how I conduct my interviews when looking to hire one. As you can see, it goes far beyond CRUD.

Is it more complex than front-end though ?


Posts les plus consultés de ce blog

Blogging isn't for me

Tool: AWS region to region latency calculator