Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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.


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


> 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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: