4 ms·

I have a love and hate relationship with this stack. On one hand it makes sense to do everything in SQL and generate the data access patterns from it. On the ot

I have a love and hate relationship with this stack. On one hand it makes sense to do everything in SQL and generate the data access patterns from it. On the other hand pushing business logic into the database has it's disadvantages - Scaling Databases is hard, - It's easier to scale a stateless application server rather than a stateful database. - SQL is still hard to maintain - Adding features using Postgres Functions means you have an additional language to maintain. The code might be spread across different migration files. Maintaining these functions long term has it's own issues.

antupis 5y ago
How about adding tool like dbt there.
- glogla 5y ago
  Dbt is for analytics. It expects you to have some "raw data" and then building bunch of models and reports off of it. I do think dbt is the answer for most of analytics, but for CRUD stuff with business logic it's not going to help you.
qaq 5y ago
You can write functions PL/Python or whatever other availible languages. It's trivial to have well structured files with functions that you auto generate migrations from.
- oreilles 5y ago
  Hell you can even write Postgres functions in Javascript with PL/V8.
glogla 5y ago
I'm on a similar boat. I really really like the idea of this stack. You are going to have the pains of a database (migrations and scaling) anyway, all your data is in a database, so why not put everything there, right? And lot of business logic fits SQL and transactions very well - like finance stuff - relying on SERIALIZABLE is probably less work than writing your own locking for moving money around. But I think the tooling is not really there, and developer experience directly translates to both productivity and team attrition so that's a really big problem. Also, lot of logic does not fit into SQL very well, say "give me a pdf" or something. Most importantly, most developers are used to think procedurally and SQL is not natural to them. And to let my inner corporate manager speak, Java or Python or node backend developers are everywhere, while for something like this you need specialized people.
city41 5y ago
I agree but I would still argue there are types of apps where this approach can be nice: prototypes, internal tools or small apps that have modest backend needs. I took this approach via Supabase and I love that I basically don't work on the backend at all.

antupis 5y ago

How about adding tool like dbt there.

glogla 5y ago
Dbt is for analytics. It expects you to have some "raw data" and then building bunch of models and reports off of it. I do think dbt is the answer for most of analytics, but for CRUD stuff with business logic it's not going to help you.

qaq 5y ago

You can write functions PL/Python or whatever other availible languages. It's trivial to have well structured files with functions that you auto generate migrations from.

oreilles 5y ago
Hell you can even write Postgres functions in Javascript with PL/V8.

glogla 5y ago

I'm on a similar boat. I really really like the idea of this stack. You are going to have the pains of a database (migrations and scaling) anyway, all your data is in a database, so why not put everything there, right? And lot of business logic fits SQL and transactions very well - like finance stuff - relying on SERIALIZABLE is probably less work than writing your own locking for moving money around. But I think the tooling is not really there, and developer experience directly translates to both productivity and team attrition so that's a really big problem. Also, lot of logic does not fit into SQL very well, say "give me a pdf" or something. Most importantly, most developers are used to think procedurally and SQL is not natural to them. And to let my inner corporate manager speak, Java or Python or node backend developers are everywhere, while for something like this you need specialized people.

city41 5y ago

I agree but I would still argue there are types of apps where this approach can be nice: prototypes, internal tools or small apps that have modest backend needs. I took this approach via Supabase and I love that I basically don't work on the backend at all.