3 ms·

No. This is not a postgres extension. It is a standalone server application (built with Haskell), so you have 3 pieces: postgres itself, postgrest and a fronte

No. This is not a postgres extension. It is a standalone server application (built with Haskell), so you have 3 pieces: postgres itself, postgrest and a frontend layer/app/site (it doesn't have to be a web browser btw). The intention is to replace alll of the dumbass CRUD api's that we normally build for each project. With that capability you can build like 95% of what you need on the frontend side, most likely. This assumes you will put all of your extra business logic in the frontend. Wether or not that is the right thing to do is another discussion, but this projects can be super helpful, esp for internal projects that's never on the public web. Or go for it, just tripple check that you aren't opening yourself up for attacks. So no, it doesn't expose your postgres instance directly to the internet, that would be nuts. It's just a server application that essentially generates an endpoint for each table and it enforces all the rules and constraints of the schema (as close as possible) without you having to code all those things by hand. That's the short version, it has a ton of other great features. I recommend you read the docs, they do a nice job of explaining what it does and where it fits.

BatteryMountain 5y ago
There is a nice graphic here: https://postgrest.org/en/v9.0/tutorials/tut0.html https://postgrest.org/en/v9.0/tutorials/tut0.html
throwaway81523 5y ago
This still sounds nuts. It lets the web client (controlled by the user, which in this context is pronounced "attacker") do any db queries/updates that the backend application in a normal app stack could. Who wants to write their whole app in browser JS anyway? Even if you do want to do that, do you end up having to write the sensitive parts it as psql stored procedures to stop the client from pwning the database?
- Izkata 5y ago
  I haven't used it myself, but my understanding was that it relies on two things to keep data safe: * Postgres has a pretty extensive role/permission system that PostgREST uses to prevent users from accessing rows they're not supposed to see: https://postgrest.org/en/v9.0/auth.html#users-and-groups https://postgrest.org/en/v9.0/auth.html#users-and-groups * The tables aren't necessarily what you want to expose anyway, you can prevent access to tables directly and use functions and views as the interface instead: https://postgrest.org/en/v9.0/schema_structure.html#functions https://postgrest.org/en/v9.0/schema_structure.html#function...

BatteryMountain 5y ago

There is a nice graphic here: https://postgrest.org/en/v9.0/tutorials/tut0.html https://postgrest.org/en/v9.0/tutorials/tut0.html

throwaway81523 5y ago

This still sounds nuts. It lets the web client (controlled by the user, which in this context is pronounced "attacker") do any db queries/updates that the backend application in a normal app stack could. Who wants to write their whole app in browser JS anyway? Even if you do want to do that, do you end up having to write the sensitive parts it as psql stored procedures to stop the client from pwning the database?

Izkata 5y ago
I haven't used it myself, but my understanding was that it relies on two things to keep data safe: * Postgres has a pretty extensive role/permission system that PostgREST uses to prevent users from accessing rows they're not supposed to see: https://postgrest.org/en/v9.0/auth.html#users-and-groups https://postgrest.org/en/v9.0/auth.html#users-and-groups * The tables aren't necessarily what you want to expose anyway, you can prevent access to tables directly and use functions and views as the interface instead: https://postgrest.org/en/v9.0/schema_structure.html#functions https://postgrest.org/en/v9.0/schema_structure.html#function...