4 ms·
It’s not just the language, it’s schema evolution, data distribution, and exposed APIs. I don’t want to give other teams direct access to a DB and have them No
by jonhohle 4y ago
It’s not just the language, it’s schema evolution, data distribution, and exposed APIs.
I don’t want to give other teams direct access to a DB and have them Not only take a dependency on the schema, but have the ability to run arbitrary queries that may exhaust resources in ways that impact normal operations. If I expose an API, I control the access patterns and can evolve the schema separately to suit the workload.
If other teams need a replica to perform their arbitrary queries, I’d much rather have them using a richer data model that they can normalize into whatever form suits their needs than have to conflate that into a source of truth data store.
If you have a single business unit and can get away with commingling concerns within a small team, great, throw it all in a single DB. If it makes sense to split, however, do it quick and early to avoid a decoupling hell that is more expensive then having split in the first place.
- andylynch 4y agoThat’s not a new problem though? The classic way to solve this in database is to expose the data API as stored procedures/views and restrict query access on the actual tables to just the DBAs - I think even MySQL which was late to the party here has had this ability for some time now.
- marcosdumay 4y ago> If I expose an API, I control the access patterns and can evolve the schema separately to suit the workload. And then they will depend on your API data schema... Yes, schema evolution is hard, but databases have many tools to help here that you will either have to recreate on your APIs or live without and have a harder time. Either way, all the trouble comes from data evolution, and any schema-only change is trivial to deal with. Data distribution is something that varies from one DB to another, they usually have very good performance that is hard to replicate on your application layer, but are very hard to setup and keep running. But the point about control of resource usage is a good one.
- yunohn 4y ago> And then they will depend on your API data schema... +100 to this
- jonhohle 4y agoBut 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 agoMoving 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 agoThat 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 agoAny 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.
- lmm 4y ago> And then they will depend on your API data schema... Which we have methods of evolving. I can put my API in gRPC and know exactly which changes will or won't break compatibility. Try doing that with a database.
- zvrba 4y ago> I don’t want to give other teams direct access to a DB [...] You don't have to. Package up necessary queries into views and/or stored procedures and grant permissions only on those. Views can also shield from schema changes.