Building a front end that other humans will use is literally art. Like in the classical sense. Confounding this with an API surface, 2nd state machine and additional team (the backend developers) turns an already difficult mission into an impossible one.
Learning how to do the whole thing is a lot easier in 2025 than it was in 2010. You have a consistent browser API surface and a chatbot that has the capability of every junior developer on earth combined at your disposal.
Being put into the position of full ownership means you will reject bad technologies out of sheer survival instinct. You'll reach for approaches like SSR. Putting all of the state on the server (by using server side rendering exclusively) means that there is no more API. No more distributed state. You are now permitted to write sql queries that directly populate the relevant HTML partials without any intermediate bullshit. Imagine how quickly we could compose response bodies if the authoritative data store lives on an NVMe disk in the same machine. You could be measuring your page render times in microseconds instead of milliseconds.
Sort of. It's actually backwards because BE work should be demand based driven by the needs of the FE.
This allows 3 things: a BE API as a promise AND division of labor (when possible and/or necessary) AND building what's essential on-demand by thinking about the FE's planning and needs first.
The problem with building a BE first is that leads to unnecessary work.
I'm a bit biased because I prefer standardized/CoC, monolithic development that doesn't have too much disconnection between the FE and BE stacks.
I don't think this is already a pattern but maybe somebody else is already doing it like the above so please let me know if it is the case