3 ms·
I think the article is kinda mixing two points here. One the one hand, it is sensible to try and keep all your business logic in one place (could be the databa
by remus 3y ago
I think the article is kinda mixing two points here.
One the one hand, it is sensible to try and keep all your business logic in one place (could be the database, could be the application) as spreading it across multiple places can make it hard to maintain.
The current trend is to do your business logic in the application and treat the db as a data storage layer. The point in the article is that if you're using this model, but then stored procs and functions start creeping in to your db and it turns out they're actually doing some heavy lifting, then this can negatively impact the performance of your 'data storage layer' (which is actually not a data storage layer any more).
- postdb 3y agoFor sure, it doesn't matter where you put it if it is in one place. If one look at company like superbase, and their product like PostgresREST. It is just way faster way to develop API, and it will scale too. Often it is about how one 'horizontally' scale.
- re-thc 3y agoPostgresREST was invented way before Superbase was around. Just a FYI.
- citrin_ru 3y agoWhy splitting logic between Postgres and an application considered worse than splitting it between multiple micro-services? A DB is a storage service with INSERT/SELECT/e.t.c. as an API. Why we cannot extend this API to include stored procedures too? Indexes are commonly used to enforce data integrity. Why we cannot use triggers to do this even better?
- KyeRussell 3y agoComparing to microservices isn’t really apt, because of how you’re (meant to) slice service responsibilities.