4 ms·

> And then they will depend on your API data schema... +100 to this

• jonhohle 4y ago
  But that API schema is unrelated to the underlying DB schema. I’ve been able to run services with different backends (eventually consistent & low latency vs transactional) exposing the same API. That would not have been possible by just giving consumers access to a DB. The DB can do everything can’t seem to understand this, for some reason.
  • marcosdumay 4y ago
    Moving the goalposts, I can see. Of course, merging different backends can not be done on the backend. Either you add a layer or you do it on the client.
    • h_r 4y ago
      That seems to be an odd way of looking at it, IMO. Most of the time, the entire point of building an API is to present consistent functionality to any consumer, not only ones under your control. Also, a well-behaved API is versioned so as to allow evolution of the API without breaking existing clients who can upgrade to new versions as they are able.
  • dvdkon 4y ago
    Any nontrivial change to the base model will mean a lot of complexity in the API layer and degraded performance. Maybe that's worth it for you, maybe if you're exposing this data to hundreds of external users who don't need high performance. But I feel that for most usecases, barebones DB access is the better option.
  • deleted 4y ago
    [deleted]
  • dragonwriter 4y ago
    > That would not have been possible by just giving consumers access to a DB. That depends on the DB's foreign table support, or equivalent, if it has it. It's certainly not categorically impossible with a DB.