5 ms·
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 us
by pilif 11y ago
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.
- tracker1 11y agoAgreed, 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.
- sitkack 11y ago> 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.
- cbau 11y agoResources only map 1-to-1 with database models for trivial applications, so certainly not the future. Still, useful for getting up and running.
- radiowave 11y agoComing 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.)
- glogla 11y agoThat's also what postgrest documentation suggests as the way to deploy it.
- e12e 11y agoWhat kind of resources do you have that can't be modelled as materialized views and make sense to store in a database?