undefined | Better HN

0 pointssublinear3y ago0 comments

What if we need the same backend to be usable by more than one client? What if those clients aren't even a SPA, but a wrapper library, or a native app? What if we need internal scripts that manage the content in the backend using the same API? What if we need to redesign the client without touching the backend?

HTMX doesn't address any of that. YAGNI is often only true for the original developers, not everyone else who has to maintain it long term.

0 comments

3 comments · 1 top-level

recursivedoubts3y ago· 2 in thread

In the article I recommend splitting your hypermedia and data APIs up into two separate concerns.

The data API can address all of the concerns you have.

The hypermedia API, being consumed by an htmx front end, can then take advantage of the strengths of hypermedia (e.g. the uniform interface giving you a lot of flexibility in aggressively refactoring your API.)

Please, read the article.

sublinearOP3y ago

There is no data that should be encapsulated in hypermedia. YAGNI in this sense is the opposite - You Are Gonna Need It

recursivedoubts3y ago

That's fine, you can build a reasonable general purpose JSON API very quickly, particularly if you aren't having it dragged around by your web applications nitty-gritty needs.

In the linked essay I am riffing on someone already recommending splitting your JSON APIs into a general purpose API for clients, and a specialized one for your web application, in order to separate these two concerns and remove the pressure that that latter puts on the former.

I recommend going further with that and adopting hypermedia for your application API, since no one else should be depending on it. I recommend this because I like the hypermedia paradigm, but it only makes sense as part of a complete hypermedia system. Trying to reuse a hypermedia API for other clients isn't a good idea and that's not what I'm recommending.

Does that make sense?

j / k navigate · click thread line to collapse