Ruminations on the 2 extreme positions of “You build the UI” vs’ “You build the UI and the API back-end for front-end”.
UI Project where I write my API’s
- Pros: Fast UI, single Ajax request usually to show screen(s), easy to digest code to that loads data.
- Cons: Fine grained, but many API endpoints, more custom SQL wrapped with services, and pressure from UI/API dev (me) to change database structure.
UI Project where I’m “Just the UI Guy”
- Pros: API dev can do the type of work they like to do. UI dev is freed of a lot of architecture burden, API support burden, and doesn’t need any knowledge of the back-end stack, how it works, nor the database setup. This allows them to laser focus on “just” UI concerns. However, as you’ll see below, this positive energy is quickly tempered into a negative burden vs. used to improve the UI.
- Cons: Slower UI, especially initial load, many Ajax requests (aka Request Waterfall), hard to digest API code in UI, easier for API to break UI because of large surface area in API change and they are unaware of how it is orchestrated (e.g. “get this, then go get that”), latency waiting for API dev to get JSON contracts, latency on UI dev (me) to give design feedback. Often speak 2 languages; “What you call a Widget vs. what the UI calls a Widget”; data on UI doesn’t always translate to the back-end. These translation areas are a huge source of bugs and miscommunications. Often the UI, especially with Types, will translate what the back-end calls a thing from JSON into an intermediary type, then translate that into what the UI _actually needs_. You still do that with writing your own API’s, but it’s usually just adding some properties, not a completely different Record.
You can guess what type of development style I, and my users, prefer. However, I’m cognizant of the power of happiness and how it relates heavily to productivity; if someone _really_ hates UI, and _really_ loves API dev, that technical burden can be passed to the UI dev to support that career path, and is better for the long term well being of the API dev, but the UI dev now has to shoulder this choice, and the user _also_ takes a negative UX hit as well.
Lots of nuance here, sure, but the above 2 has happened many times to me in different technology stacks, it’s disappointing when it “goes back to just a UI dev and an API dev”. It’s not wrong or catastrophic, just a ton of trade offs, and developer happiness has a lot of research to show it probably should overule most other concerns. That or just have a UI dev who doesn’t know back-end, and a back-end dev who doesn’t know UI which is fine too. This is why you continue to see this push for “Full Stack Devs” and things like Next.js / Remix merging UI and API together in the same file which helps the context switching a lot.