3 ms·
I find the idea of PostgREST very intriguing at first sight. Someone around with experience running this in production? Did you find any major pain points when
by polycaster 5y ago
I find the idea of PostgREST very intriguing at first sight.
Someone around with experience running this in production? Did you find any major pain points when integrating in a client app (let's say React, Svelte or alike)?
The trouble I felt in the past with the concept of DB as source of truth was to manage business logic (eq. in stored procedures) in a way, that works for a distributed team efficently.
- 0x62 5y agoI tried it via Supabase (open source Firebase clone that uses PostgREST under the hood). At the time there was no join support which was incredibly limiting, and we ended up using Hasura instead. Overall though, the user experience was generally very good and we still use it for some smaller standalone components on otherwise static websites (e.g. a mailing list signup form) where you don't need complex joins.
- andix 5y agoCan’t you use views for joins? Usually you should be fine with a few views, in most schemas, there are just a limited amount of tables you can join in a meaningful way.
- kiwicopple 5y ago> no join support Perhaps you mean no left-join support? There has been support for inner-join support in PostgREST for a few years :) (example: https://supabase.com/docs/reference/javascript/select#query-foreign-tables https://supabase.com/docs/reference/javascript/select#query-...)
- ratww 5y agoIt works pretty well with frontend frameworks, as long as you keep the interfaces simple and don't try to cheat and put business logic into the frontend. IMO the the source of truth for Views and Stored Procedures should be a git repository, where developers change them in a .sql file, and the CI tests and updates them in the databases.