> Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients I’d argue it makes it more

> Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients I’d argue it makes it more flexible, but not easier. It’s so much easier rendering html serverside than having it all done separately in React. > Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases You now also have to worry about versioning and/or coordinating releases. Mobile clients demanding a different set of APIs than web client. use graphql? Rest? > front end and the back end are agnostic to each other This is good in theory but in practice when you have to replatform the backend for example, it is often for reasons such as separating out concerns, refactoring, rewrites, or moving the frontend over to a new system etc and that usually ends up with the frontend needing to change as well. The frontend is coupled with the API contract that the backend provides and is not entirely agnostic to each other. This is pretty similar in nature to monoliths vs microservices where monoliths are by far a simpler architecture.