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.
u
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.



Security

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 ?


Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Blogging isn't for me

I hate writing. I've been working on a couple of really cool projects as of late, but I lack the motivation to write blog posts or articles on that. How do you folks do it? #javascript #opensource — Fred Charette (@fed135) December 11, 2019 I have dozens of ideas and concepts that I want to explore every day. But hours in a day are precious, there's work, family, friends, house projects, *cough* gaming *cough*. And, well, I have a lot of trouble publishing words that I'm proud of as opposed to code. I've amassed over the past few years a grand sum of 21 unpublished articles on various topics and various degrees of completeness. Ranging from tidbits of info on specific topics all the way to scientific white papers. At the root of it all I guess there's one reason why I don't publish these. I'm afraid of being outed as a fraud- the infamous impostor syndrome. I freeze at the notion that someone could look at my work and point out to me that what
Lire la suite

Tool: AWS region to region latency calculator

We had a project for work to create a secondary infrastructure in Europe, our main one being in Canada (for legal reasons). During the conversation, there was a question as to whether we would need to replicate everything, or if the European services could leverage some of the Canadian ones. Of course that would allow us to save a pretty penny on EC2 costs, but what about the end user performance impact of making requests that need to physically travel back and forth the Atlantic Ocean. I embarked on the (quick) journey to build a tool that would estimate the minimum amount of time (ms) required for a packet to make that trip, based on physics. The premise is that a packet of information may not travel faster than the speed of light. This premise is backed by the fact that the speed of light is the fastest speed at which energy, matter and information can travel. ( source ) With this constant, along with the geographical positions of AWS data-centers, plus some maths for the ac
Lire la suite