The two sources of truth are for two disparate adapters. Neither the API nor the DB define the domain, but both must adapt the domain to their respective implementation concerns.
The ontology of your persistence layer should be entirely uncoupled from that of your API, which must accommodate an external client.
I'd rather define my db domain in-code so I do not have to worry about writing the queries without type hinting.
Raw sql -> eh, I don't have the patience
Raw sql w type hints -> better, I at least get a compilation error when I do something wrong, and preferably a suggestion
ORM -> this usually introduces it's own abstraction that needs it's own maintenance, but at least it's more code-oriented.
Yes, SQL is an awesome solution to querying DB's, hence I prefer option 2
That's an awfully cynical perspective, but these terms evolved because they're useful. No one is forcing us to speak them (although they are forcing us to hear them.)
I would rather refer to affordances than to "user-facing touchpoints", because that's a more specific abstraction aimed at, specifically, interactive elements whereas "touchpoints" is, to me, vague; does it refer, also, to the merely visual aspects which "touch" our retinas?
"Friction" is a metaphor, and there's nothing wrong with that! I imagine that one monitoring a conversion funnel would naturally ask "what's causing the members of this cohort to drop out of the flow?" Well, it's friction that challenges spatial progress, and spatial metaphors make good use of some underused cognitive hardware.
"Increase stickiness... but also keep it lean", though is, at worst, an oxymoron and, at best, lazy along the lines of "... just make it good and not bad."
My perspective may come across cynical, although I am not a cynic, I just see this as what I observe. I am usually described as a very optimistic and patient person.
My position is the perspective of a former freelancer who had to translate that lingo into actual actionable steps. The perspective of someone who builds a website alone in a day, while building one on a month when guided by committee.
I have nothing against specialized language, if it serves a purpose as I mentioned in my philosophy example. For some concepts the specialized words are the only ones giving you the precise language needed to reference them in a meaningful way. What I dislike is needless specialized language by people whose job is it to let others interpret what they meant. The ambiguity is of course a feature on multiple dime sions, they can decide whether you read the runes correctly after the fact.
I really like these sorts of frameworks from an architectural perspective, but what's the use-case? Maybe I'm too SPA-pilled, because to me all the fun of Web development is in providing really fluid, skeuomorphic experiences like those enabled by, eg pragmatic-drag-and-drop[0] or yjs[1].
I just struggle to envision what application benefits from the efficiency that this or htmx offer, but from neither the ultra-interactive, nor the ultra-collaborative. Maybe updating stock ticker prices? Fast-service back-of-house ticketing displays?
I would love to feel called to reach for this library.
Relying on server side as the source of truth inverts complexity. Suddenly 90% of the modern webs problems evaporate. Turns out building everything on top of a shadow dom in the client creates a boatload of unforced errors.
The sweet spot is everything between a static website and a full SPA, which is actually most of the web. Think e-commerce (filtering, cart updates, pagination), dashboards (refreshing metrics, notifications), admin interfaces (inline editing, form submissions), content-heavy sites (live search, comments, modals). Basically any app where the primary interaction is 'user does something, server responds with updated content'. For drag-and-drop kanban boards or collaborative editors, you're right, µJS is not the right tool. But those are a small fraction of what gets built every day. Most web apps are glorified CRUD interfaces, and for those, server-rendered HTML fragments are simpler, faster to develop, and easier to maintain than a full SPA.
The ontology of your persistence layer should be entirely uncoupled from that of your API, which must accommodate an external client.
In theory, anyway.
reply