3 ms·
There is PostgREST, which is just a thin wrapper REST api around a Postgres database: https://postgrest.org/en/stable/ https://postgrest.org/en/stable/
by holtalanm 5y ago
There is PostgREST, which is just a thin wrapper REST api around a Postgres database:
https://postgrest.org/en/stable/ https://postgrest.org/en/stable/
- rattray 5y agoAnd its graphql counterpart, postgraphile (described elsewhere on this thread: https://news.ycombinator.com/item?id=26823819 https://news.ycombinator.com/item?id=26823819)
- xemoka 5y agoThis is such a useful abstraction. I love working with PostGREST and have used it quite often for quick services (e.g. a vote button on a static site), internal tools (recently a covid checkin-screener), and for Proof of Concepts (postgres+postgis-powered full text search for address lookups in a webmap without using an external geocoder). I personally have yet to use it for something with more than 200 users, but it sounds like others certainly have successfully. Supabase (https://supabase.io/ https://supabase.io/) uses this for parts of their backend.
- ufmace 5y agoI thought of this when I first read the article title, and I think it's a decent compromise that mostly addresses the concerns in the other comments. Supporting truly arbitrary SQL seems too high-risk to allow from the front-end. PostgREST supports a simple subset in a HTML-like language that's fairly unlikely to have any unpredictable/negative consequences. I think it has limits for query time and result size built-in already too. You do have to get used to setting up the correct security constraints in Postgres natively though. Strangely enough, I hardly ever see anyone really use the Postgres security checks. Postgrest is pretty much the only use case I've ever heard of.