undefined | Better HN

0 pointsthrowaway778310mo ago0 comments

I have repeated this elsewhere. APIs for UI tend to diverge from APIs in general in practice.

For applications that are not highly interactive, you don't quite need a lot of tooling on the BE, and since need to have a BE anyway, a lot of standard tooling is already in there.

React style SPAs are useful in some cases, but most apps can live with HTMX style "SPA"s

0 comments

whatnow3737310mo ago

Agreed. We started with one API to rule them all. What happened? Now we got two.. and now we have to communicate like this:

“So the backend gave this weird …”

“What backend?”

“The backend for the frontend…”

“So not the backend for the backend for the frontend?”

I jest, but only very slightly.

throwaway7783OP10mo ago

Exactly. And state is in two places now. It's like building two applications and trying to somehow keep them in sync.

qudat10mo ago

> APIs for UI tend to diverge from APIs in general in practice.

I'm arguing to just use a single API, not creating one for UI, at least when you want things to be simple for multiple clients.

recursivedoubts10mo ago

https://htmx.org/essays/splitting-your-apis/

j / k navigate · click thread line to collapse