You can't just be a backend developer.
(most of the time)
Last week I came across Asko's blog post on Reddit (r/programming) about why he doesn't want to work in the front end anymore. I had similar feelings three years ago after working as a full stack developer and insisted on taking a pure backend role with my current employer. Ignoring the frontend turned out to be a colossal mistake and caused many problems in our architecture.
I will extend Asko's complaints with some of my own. Most frontends using SPAs are vanity projects. Simpler approaches like server-side MVC could lead to quicker deliveries, but that doesn't excite developers and product designers. Without strong design direction, developers can spend a ton of time reworking aesthetics and not adding features. Finally, UI's tend to atrophy faster than any other codebase in a platform. I believe this has less to do with technology and more to do with the experience of developers working in the codebase and the lack of investment in quality software practices in the frontend.
When engineers run away from the UI, we think we will find comfort and simplicity in servers, databases, and APIs. In actuality, we have pushed ourselves further away from the user, and consequently, the product. In our place, we assign junior developers to frontend roles because we think the blast radius of bad decisions will be limited. We maintain our awareness of features by participating in design and architecture and extricate ourselves from trivial UI conversations. However, these conversations can drastically change how the backend is supposed to work, leaving backend developers to make hasty changes to support the decision or, worse, the UI team to figure out workarounds suboptimal to overall system stability (see below).
Neglecting the UI can be dire. It leads to obvious usability problems and terrible customer experience. From a backend perspective, the frontend can induce various issues, including increased load, improper error handling, and subversion of safeguards (like security). If you also take away experience and attention from the frontend, you're guaranteed to incur classic software problems that turn your architecture into a big ball of mud. I contend this is why we (as an industry) re-platform the frontend more than the back (not because technology changes so rapidly).
No matter how much you don't like the frontend, you can't ignore it and be a "backend developer". Instead, I propose you become a 3/4 stack developer. This involves being familiar with frontend technologies, but not necessarily competent in them. You must make contributions to the frontend, specifically at the integration points with the backend (this is where the extra 1/4 comes from), but you won't have to be aligning text, styling buttons, and tweaking Webpack. Your primary responsibility will be to ensure the UI correctly consumes the API, including propagating errors correctly and following security protocols. You should also monitor the evolution of the UI and advise on how changes can be best facilitated by the backend. Most importantly, it would be best if you kept an eye on code quality and mentoring junior developers. The alternative is letting the frontend become a problem for you as a backend engineer.
- The amount of attention you need to spend in the UI (as a backend developer) is inversely proportional to the skill level of your frontend developers/team. Experienced frontend engineers will make your life a lot easier because they understand how the frontend can cause issues with the backend.
- I also believe the idea of a "3/4 stack developer" works in the opposite direction (with a frontend focus). UI engineers can benefit greatly by learning how to write some of the API code in the backend. In this way, they can tailor backend models to frontend representations, transforming data before it's sent to clients. Netflix pioneered a form of this architecture using a FaaS (Function as a Service) Edge API.
- Leadership is obviously important in ensuring the UI doesn't develop into a big ball of mud. This post was written from the point of view of the individual contributor and how neglecting one tier of the architecture can affect them.
Stumbling my way through the great wastelands of enterprise software development.