Very roughly, there’s “frontend” engineering (building the parts of a website or application that users interact with directly) and “backend” engineering (building the parts that store data and power the frontend). In practice, there’s a large gray area in between.
Any handoff creates friction. Frontend engineers might be waiting for an API route to be developed, a database schema to be migrated, or even just for their code to be deployed. Developer tools that empower engineers to do more by themselves are always in high demand.
What if the frontend is eating the backend?
The ouroboros (Greek: οὐροβόρος) is an ancient symbol of a serpent or dragon eating its own tail. It symbolizes the perpetual cycle of creation and destruction and is often used to represent the idea of something endlessly re-creating itself.
The frontend ouroboros might exist for a few reasons:
- It’s easier to commoditize the lower layers. It's why we no longer have as many database administrators (now DevOps), DevOps engineers (now platform engineers), and platform engineers (now developer-friendly cloud PaaS).
- There are a magnitude more frontend developers than backend developers. While one isn’t necessarily “easier” than the other, if a company requires any sort of user-facing software (even internal), it requires frontend engineers.
- Frontend frameworks have shorter software half-lives. Requirements up the stack change more often and are less generalizable.
- Frontend architecture often dictates backend architecture. A framework that deploys to the edge (e.g., NextJS) requires certain considerations for the API layer (database proxies/connection pooling, NAT gateways/network overlay design, etc.)