4 ms·

I use PostGREST a lot, but with strong guardrails. IMO you should always have a real API layer, and use this just for a convenience to do the base load. Like al

I use PostGREST a lot, but with strong guardrails. IMO you should always have a real API layer, and use this just for a convenience to do the base load. Like all these tools, once you go to real world requirements, adapting the tool is worse than what it is trying to replace (SQL + some language and framework). Already PostGREST is getting complicated, additions like this will make it less attractive to me.

steve-chavez 3y ago
> Already PostGREST is getting complicated, additions like this will make it less attractive to me. This feature[1] actually simplified a lot and removed a lot of magic assumptions in the PostgREST codebase. It goes in line with REST as well — SQL functions are REST resources and HTML is just another representation for them. Most of the code you see here is pure SQL and plpgSQL. The only PostgREST-specific part is the CREATE DOMAIN. Right now most users view PostgREST as a HTTP->JSON->SQL->JSON->HTTP service and we're trying to turn that into HTTP->SQL->HTTP. If that's not some true top level simplification, I don't know what is! [1]: https://postgrest.org/en/stable/references/api/media_type_handlers.html https://postgrest.org/en/stable/references/api/media_type_ha...