I have been working as a backend developer for 2 years now, in a small team of 4 developers. During these 2 years, I had the opportunity not only to develop software, but also opinions. The following are some of them, that I think are worth sharing.

1. Developers should not manage servers

As a software developer, you may be perfectly capable of handling everything related to server management: setting up and provisioning VMs, configuring load balancers, applying security updates, deploying new versions of your software, etc. You may even like doing all these (but jeez I don’t!). However, the reality is that your precious time as a developer would most certainly be better spent actually developing software.

Platform-as-a-service (PaaS) providers such as Heroku have been around for quite some time now, and Infrastructure-as-a-Service (IaaS) offerings such as Amazon Web Services (AWS) make it easier than ever to build web applications by assembling building blocks. And for those who still need direct access to actual VMs for some reason, you can still avoid managing everything all by yourself, thanks to orchestration services such as AWS Elastic Beanstalk.

My most useful discovery of 2016 was a framework called Serverless, which allows to easily “build auto-scaling, pay-per-execution, event-driven apps on AWS Lambda”, and will soon support more “Function-as-a-Service” providers. Try it, it is a truly amazing piece of software.

2. Modern backend development should be more about architecture than writing code

I have been using Gliffy quite a lot recently, to create things like this:

As a well-known plumber with a moustache would say: Here we go! We get a backend that allows someone to be notified when a “thing” changes status, and to retrieve the last known state of that “thing” on-demand.

Implementing this backend involves writing almost no code at all. The only component that runs custom code is the API Handler, which lives on AWS Lambda. Such an infrastructure could be set up in minutes using Serverless. It would scale automatically, and its monthly cost would depend on its actual workload.

That’s exactly what building software using IaaS is all about: writing less code. But you must spend more time designing your architecture, and perfecting the art of not reinventing the wheel.

3. The front-end should dictate the API design, not the other way around

‘Member the pre-UX era when most applications basically consisted of graphical representations of the underlying relational databases?

‘Member when most apps were graphical representations of the underlying RDBMS?

Well, guess what?

“For the times they are a-changin’” — Bob Dylan

Applications are becoming more and more complex, and are now built with a desire to move complexity away from the user. Which means that simply implementing GET and POST endpoints for each database entity and then sending the spec to the front-end guy might not be the most sensible thing to do for anyone who cares about performance.

‘Member — the front-end guy works for the users of the application, but you work for the front-end guy. He is the one who will end up using your API, so it is his needs that should guide your design.

For instance, it should not be considered normal for the front-end to have to call 3 different API endpoints to fetch all the information that is displayed in a single view. It should also not be considered OK for the front-end to fetch a bunch of unneeded data so it can display a small subset of all the information returned by the endpoint.

But how to avoid this without the API becoming a UI-driven mess? That brings me to my next point.

4. The future will be much brighter without REST APIs

For years now, REST APIs have been one of the most painless ways of transmitting data from software components to other software components. But REST APIs still come with their own pains: for instance, it is almost impossible to design a decent API that will respond in an ideal way to every use case from the front-end. Other pains include the repetitiveness of implementing all these endpoints, and the hell of API versioning and backward compatibility.

Now, imagine a paradigm where your API has to provide only one endpoint, and that endpoint allows the clients to fetch exactly the data they need. You still have to care about backward compatibility, but not so much about versioning.

Guess what? That paradigm exists — it is called GraphQL — and some people call it the future.

5. Thou shall not patronize front-end developers

Some backend developers have the feeling that front-end developers are lesser creatures. After all, they just stick a bunch of HTML and CSS together with some Document.getElementById JavaScript, right?

Except they don’t.

With applications becoming more and more complex, and the rise of front-end frameworks such as ReactJS and everything related, there is no doubt that front-end development has become “real” software development. It is not about plugging some JavaScript into HTML anymore, it is the other way round.

I ‘Member — You ‘Member?