It's an interesting beast: it has almost no configuration at all, you just point it to one database schema, and it then uses the postgres permissions system to decide what tables & views to expose, and who gets to see them.
The only part of it that was a little tricky was creating multiple database users for anonymous views off the internet vs. internal staff who would want to do more than just select some rows.
PostgREST exposes everything within a particular schema and then every call gets translaed into a query and executed. It's the database (PostgreSQL) that is deciding if the query will be executed or it will raise a permissions error. PostgREST just kind of says "hey db, this is the current user. Now run this query for him"
From a high level, postgrest is just a pure function that translates a rest call to a sql query and executes it with the privileges of the user that is making the request. The database does all the heavylifting
[1] https://db.in.tum.de/downloads/publications/hyperspace.pdf
Any more you can add about the experience of "writing" the back-end in PostgREST if you're hanging out in this thread, Billy?
Lacking: I didn't really find anything lacking; it was able to do everything I needed. I'm a pretty basic end-user, not an expert. At first I was confounded by the limitation of one schema per PostgREST instance; but that's easy to work with or work around. I created a single "api" schema which contained nothing but views of tables that lived in other places. You can also just run more than one instance of PostgREST if you want to expose more than one schema.
One trick though, if you specify the schema as an empty string "" then entities in the query will not be fully qualified, so this will give the search_path the ability to do it's work
