My journey into the land of web technologies continues in the space and time dimension for personal and professional reasons :) In the last five to ten years, my go-to approach for creating a web-based application was REST and API-first, start with the server, and then build a single-page application on top. This aligns nicely with a domain driven design, where the starting point is the domain data model.
In many cases, the resulting server was then mostly a thin wrapper around the data storage layer. Add the usual OpenAPI spec on top, serve JSON or XML, and it is a very nice and formal system. But it does require more client side logic to achieve an actual usable system, and this client side logic is where the trouble usually started, to be witnessed from the ongoing web framework churn.
It is however not a given that the boundary between backend and frontend needs to be designed in terms of exchanging typed objects. Back in the Web 1.0 days, we exchanged data formatted for rendering, and there was no formal link between that data and the domain model. Same as sending ANSI escape codes to a TTY, or using the X Window Protocol over TCP/IP :)
This raises the question whether “API first” should be automatically be the first choice, or whether there should be a checkpoint before going down that route. And if it is not “API first,” what is then first?