4 ms·
This is pretty good. It will allow us to use PostgREST as an API endpoint to query the ClickHouse database directly
by graovic 10mo ago
This is pretty good. It will allow us to use PostgREST as an API endpoint to query the ClickHouse database directly
- justtheory 10mo agoOoh, neat idea!
- saisrirampur 10mo agoGood idea! Btw, ClickHouse does provide a HTTP interface directly, too! https://clickhouse.com/docs/interfaces/http https://clickhouse.com/docs/interfaces/http
- deleted 10mo ago[deleted]
- oulipo2 10mo agoWhat are the typical uses of PostgREST? is it just when you want to make your database accessible to various languages over HTTP because you don't want to use an ORM and connect to your db? But besides that, for an entreprise solution, why would you use PostgREST to develop your backend rather than, say, use an ORM in your language and make direct queries? (honest question)
- lillecarl 10mo agoYou skip the backend entirely and query from the frontend. PostgREST and Postgres is your backend. If you want extra sauce on top you route those paths to an application that does whatever extra imperative operations you need.
- jascha_eng 10mo agoThis always sounds super messy to me but I guess supabase is kind of the same thing and especially for side projects it seems like a very efficient setup.
- oulipo2 10mo agoSo a kind of "mini-Firebase" ? and then you have security through row-based security? But this also means your users can generate their own queries, possibly doing some weird stuff taking down the db, so I assume it's more for "internal tools"?
- charrondev 10mo agoYeah definitely not for public facing things of any capacity. No matter your size unless you have a trivial amount of data, if you expose a full SQL query language you can be hit be a DOS attack pretty trivially. This ignores that row level security is also not enough on its own to implement an even moderately capable level of access controls.