Backend vs. Frontend: A Developer's Frustration
The author expresses frustration with the common debate surrounding backend vs. frontend development, arguing that it often misses the practical realities of building software. He believes developers often get bogged down in technical details like REST vs. GraphQL, losing sight of the user experience and developer productivity.
The Problem: Backends Designed for No One
A key point is that most APIs serve only one client (usually a frontend). The author argues that backends are often overengineered for imaginary users instead of being tailored to the specific needs of the frontend team. Conversely, frontends are often expected to adapt to rigid, preexisting APIs, leading to unnecessary complexity.
The Trigger: A Tweet About a "Bad" API
The author was triggered by a tweet criticizing a REST API that returned a JSON blob with fields named "table1," "table2," and "Main." The critic argued that this tightly coupled the API to the UI. The author strongly disagrees, stating that if the API is exclusively used by that frontend, then building it around the UI's needs makes perfect sense.
An Anecdotal Example: Backend Blocking Frontend
The author shares a story about a personal experience where a backend developer blocked a pull request for an endpoint specifically designed for a UI. The backend developer insisted on using existing, generic REST endpoints. The result was significantly worse performance (13 requests vs. 2 efficient DB queries), increased database load, and a poor user experience. Despite profiling and demonstrating the performance issues, the backend developer initially refused to budge.
The GraphQL Argument and Its Alternatives
The author highlights how GraphQL's rise stems from frontends needing specific data and avoiding unnecessary data transfer. However, he questions why creating tailored backend endpoints for frontends can't be easier. He argues that if building a custom endpoint is relatively simple, it's often a better solution than forcing the frontend to adapt to a generic API.
The Tech Debt Myth
The author challenges the idea that creating UIspecific APIs constitutes technical debt. He believes that making the user experience worse by forcing the frontend to use generic APIs is often a greater form of technical debt, forcing the frontend to build complex workarounds.
Backend Should Serve the Frontend
The author emphasizes that the purpose of APIs is to serve clients, and if the client is a frontend, the API should be optimized for that frontend. He notes the trend towards tools like HTMX, which allow backends to return HTML fragments directly, further blurring the lines and optimizing for user experience.
Backend for Frontend (BFF) and Modern Tools
The author is a strong proponent of the Backend for Frontend (BFF) pattern. He highlights how tools like Next.js, Remix, and trpc are making it easier to build the right backend for the frontend, reducing complexity and improving developer productivity. He gives the example of TRPC where you can right click and go to definition from the front end to your back end, with complete type safety and data inference.
Rethinking the Traditional Divide
Modern approaches like React Server Components are blurring the lines between backend and frontend. Instead of thinking in terms of separate teams and abstracted API layers, the focus shifts to what data is needed to render the UI, allowing components to directly request the data they need from the backend.
The Bottom Line
The author reiterates that if a REST API is exclusively used by a specific UI, it should be designed to serve that UI in the best possible way. He urges developers to stop architecting for imaginary users and instead prioritize the needs of the frontend and the end user. If a slightly different database query is needed, just do it, without unnecessary red tape.