Hacker News Reader

Comment by Onavo | Hacker News Reader

With this you don't need to have two sources of truth on the backend. Previously you will end up with one set of DB ORM level validation and a second set of validation on the data transfer object and you have to make sure the types line up. Now the data transfer object will automatically inherit the correct types.

View on HN

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.

In theory, anyway.

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

Well yeah, of course. Sorry, when I said "DB" what I should have said was "data-layer," and this can include: repositories, ORM models, query-builders, etc. All of these are type-hinted "db domain in-code" and, still, not one coupled to your API.

Exactly, that's the idea.

Reply on news.ycombinator.com