Hacker News Reader

Comment by pilif | Hacker News Reader

Contrary to many other "expose a RDBMS schema as an API" solutions, this one is interesting due to its very close tie-in with postgres. It even uses postgres users for authorization and it relies on the postgres stats collector for caching headers.

I also very much liked the idea of using `Range` headers for pagination (which should be out-of-band but rarely is).

I'm not convinced that this is the future of web development, but it's a nice refreshing view that contains a few very practical ideas.

Even if you don't care about this at all, spend the 12 minutes to watch the introductory presentation.

View on HN

Resources only map 1-to-1 with database models for trivial applications, so certainly not the future. Still, useful for getting up and running.

Coming from the old world of business IT where "integrate everything with the relational database" is standard procedure, it's certainly not unusual for the database to be a place where abstractions are defined(1), so what you expose via PostgREST may not in fact be a close match for the underlying data model.

(1 - In fact with me it's pretty much a matter of policy: any external system should access data via views named for the external system. Then, as inconvenient as it sometimes is, Postgres' dependency mechanism will keep me right about which fields in which tables are depended upon by which external systems.)

That's also what postgrest documentation suggests as the way to deploy it.

What kind of resources do you have that can't be modelled as materialized views and make sense to store in a database?

Agreed, even though I don't care for exposing the database quite this directly, it is a very interesting approach...

I'm also unsure of using the DB's authentication system. While approachable, I'm at a place where imho, for most systems there is a conflation of users, accounts, and logins. IMHO, a user may only have a single account, but a modern system should support multiple logins... Supporting social/jwt/oauth style logins in addition to local database backed logins is generally the best option for public facing sites/applications.. and even then jwt/oauth will allow for more seamless integration with internal SSO options.

Then again, this type of approach may work well if you want to be able to use it as an additional abstraction of your database access from a UI backing API.

> Agreed, even though I don't care for exposing the database quite this directly, it is a very interesting approach...

It is up to the developer to use this responsibly. I don't think the creator is suggesting to drop PostgreSQL instances directly onto the net. This would be ideal in a layered backend, and in fact, makes systems way more composable.

Reply on news.ycombinator.com