Hacker News Reader

Comment by jimbokun | Hacker News Reader

As long as you have good interfaces in your code to make it possible to swap out Postgres to more specialized components when needed, I think it’s a good idea.

Saving ops resources by managing fewer services when getting started is a good idea, until scale necessitates dedicated technologies for certain components.

View on HN

I wouldn't even worry about coding to interfaces. When you need to replace Postgres because you have more than 1M users, you will probably have the revenue to refactor your code to swap out Postgres dependencies. Because you have good integration and E2E tests, right?

Good tests are a lot easier to write with good interfaces.

Database abstraction layers are leaky, if you don't test things like isolation levels or other tricky behaviors, those tests will have limited value.

Limited value is better than no value.

At such time you will also have plenty of interesting new problems that require changing most of your code anyway.

I agree that hedging against having to move from a FOSS database is pure waste.

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.

To 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.

> 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.

Often writing abstract interfaces costs more then switching things out by changing your code. So it's often better to keep concerns separated and make it so that code is easy to change, but creating abstract interfaces is often not worth it for a lot of products.

YAGNI!

Reply on news.ycombinator.com