This. The mental model of an API with a frontend deployed as static resources just happens to be very attractive. Even more so when the SPA isn't the only frontend, or when you don't know that the SPA will remain the only frontend forever. When you have an SPA sitting on top of an API, introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.

If you have a huge org working on the project you might actually succeed in sticking to that architecture even when serving as plain old HTML, but smaller teams are likely to eventually write full stack spaghetti (which might still be fine for some use cases!). Once there was a fashionable term "progressive web app", with manifest workers optionally moving some backend stuff into the browser for offline-ish operation, and these days I also see a parallel pattern: progressively moving a browser UI into an electron-esque environment, where you can features requiring more local access than the browser would allow.

▲

jiggawatts 4 days ago | parent [-]

> introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.

This never happens, for some values of never.

When a SPA app is initially developed, the "client" and the "API" are moulded to each other, like a bespoke piece of couture tailored to an individual's figure. Hand-in-glove. A puddle in a depression.

There is absolutely no way that some other category of platform can smoothly utilise such a specialised, single-purpose API without significant changes.

The reality is that most SPA apps are monoliths, even if the client app and the API app are in different Git repos in order to pretend that this is not the case.

	▲	Anamon 21 hours ago \| parent [-]
		That's absolutely not my experience from any of the SPAs I've worked on. If the API used by the SPA is so "specialised, single-purpose", then that isn't something inherent to SPAs, only inherent to developers (or architects) who are inexperienced or bad at their job.