4 ms·
That will make you lose a lot of productivity boosts SQL can give you. Obviously, if you anticipate to have very high traffic and applicable usage patterns, do
by cube2222 4y ago
That will make you lose a lot of productivity boosts SQL can give you.
Obviously, if you anticipate to have very high traffic and applicable usage patterns, do use that advice, but if your apps anticipated usage pattern is in fact not "very high rps per buck made", then I recommend the opposite.
I've went the whole way from very-well-abstracted-away services/repositories to an almost complete lack of abstraction.
Direct SQL or ORM in your functions, operating on many models at once, with a real postgres database available to all your unit tests, treating the SQL code as part of your application logic. Transaction per test so that unit tests are fast to run.
I've been very happy since. SQL is very powerful if you use it as SQL and not as a glorified KV store.
- lukeramsden 4y agoTo me, good modularity at the data layer doesn't mean abstracting away Postgres or even SQL. To me, it means having a separation of concerns between loading data, writing data, and _processing data as domain objects_. Don't have your core business logic operate over database rows, but in-memory objects. You can test the loaders/writers separately to your actual logic at that point.
- cube2222 4y ago> Don't have your core business logic operate over database rows This is the part where I don't agree, as SQL is very expressive, and needlessly loading data to your app is also not performant (making the transition to something else required sooner). I think writing parts of your business logic in SQL that make sense to be written in SQL is just fine. If you only use it to load and write entities, then that is basically a glorified KV store.