4 ms·

I like data. A database is created to handle it, give you tools to query, modify, scale, secure the data. A rest api... how and why should it be responsible fo

by zkomp 9y ago

I like data. A database is created to handle it, give you tools to query, modify, scale, secure the data. A rest api... how and why should it be responsible for your data? It solved a different problem. You might not even need a database I guess, and then anything goes. I need and like my database, and have suffered trying to get along with different ORMs. SQL is so good at what it is designed to do if you just let it. (And why just one rest api? How about 100 restapis, some microservices, some web apps, some background workers, many different languages. One database. No ORM)

scarface74 9y ago
One database is still an issue. When you have a clear slice with one microservice being in charge of one set of data, it's easier to scale, slice, rewrite, and you can deploy and iterate faster without interdependencies. And you lose all of the benefits of microservices if there is still a tight coupling between unrelated (from a domain perspective) to tables.
zkomp 9y ago
(have we come to some max nesting level here, cant reply to the child comment) One db can be a problem, or a strenght depending on the domain; And I really dislike religious design, esp microservices. I have less problems by avoiding ORMs (and religios microservice arch, or fundamentalist interpretations of rest) Database handles the shared state in a heterogenous environment. We need it to be centralized to keep track of money, the apps can't do that, two independent databases cant do that either. It must be one system that guarantees concistency. It works great, there is no downtime. The interfaces are defined, the database stands alone, updates are deployed separately.
- scarface74 9y ago
  Database handles the shared state in a heterogenous environment. We need it to be centralized to keep track of money, the apps can't do that, two independent databases cant do that either. Why can't apps "keep track of money"? I'm assuming you're referring to transactions. Apps can create transactions and you can share transactions across apps using distributed transaction (I'm not saying distributed transaction is a good idea).

by zkomp 9y ago

scarface74 9y ago

One database is still an issue. When you have a clear slice with one microservice being in charge of one set of data, it's easier to scale, slice, rewrite, and you can deploy and iterate faster without interdependencies. And you lose all of the benefits of microservices if there is still a tight coupling between unrelated (from a domain perspective) to tables.

zkomp 9y ago

(have we come to some max nesting level here, cant reply to the child comment) One db can be a problem, or a strenght depending on the domain; And I really dislike religious design, esp microservices. I have less problems by avoiding ORMs (and religios microservice arch, or fundamentalist interpretations of rest) Database handles the shared state in a heterogenous environment. We need it to be centralized to keep track of money, the apps can't do that, two independent databases cant do that either. It must be one system that guarantees concistency. It works great, there is no downtime. The interfaces are defined, the database stands alone, updates are deployed separately.

scarface74 9y ago
Database handles the shared state in a heterogenous environment. We need it to be centralized to keep track of money, the apps can't do that, two independent databases cant do that either. Why can't apps "keep track of money"? I'm assuming you're referring to transactions. Apps can create transactions and you can share transactions across apps using distributed transaction (I'm not saying distributed transaction is a good idea).