4 ms·
This throws away most of what your database can do for you. I personally like to do authorization at the database layer. There are a tons of other things a DB c
by csomar 2y ago
This throws away most of what your database can do for you. I personally like to do authorization at the database layer. There are a tons of other things a DB can do, like trigger a webhook. Are you going to frequently pull from your DB for live updates?
I think OP issue is that he didn't understand what mock tests actually tested against. They are called mock for a reason. There should be a better way to provision a database when running tests and have a full simulated environment.
- Spivak 2y agoI think you've swung the other way a bit too far, I've never seen application logic split between the app and database not become a huge PITA. I would never have my DB trigger a webhook for me but I would have it act as a message broker back to my own code that triggers a webhook. I don't want my DB ever initiating an outbound connection.
- motorest 2y ago> This throws away most of what your database can do for you. I personally like to do authorization at the database layer. The whole point of writing maintainable software is to throw away most of what technologies can do, because you are way better off if you do not make the mistake of following that path. For example, at a first glance doing auth at the database layer is a huge mistake. You design your systems with a few nodes having exclusive access to the DB to ensure your access is secure without having to waste the overhead of checking credentials in each db access. The main design trait is speed. But you do you. > There are a tons of other things a DB can do, like trigger a webhook. There are plenty of reasons and hard learned lessons behind principles such as separation of concerns.