4 ms·

At some point CRUD goes from being pure CRUD to mostly CRUD with a few special requirements - e.g. complex RBAC rules, decorating data, API versions, integratin

At some point CRUD goes from being pure CRUD to mostly CRUD with a few special requirements - e.g. complex RBAC rules, decorating data, API versions, integrating third-party APIs, scaling. They're easy to do in most app frameworks (Laravel, Django, Rails), tricky in something like Postgrest. I haven't use Hasura.

cpursley 4y ago
You can get really far with database views (decorating data, especially), functions (all sorts of biz logic) and Postgres roles for RBAC. But I hear you on integrating with 3rd party APIs, etc. Fwiw, there's a number of PostgREST backend client libraries to help with that.
- blowski 4y ago
  Totally agree that it's possible. But at some level, it may just be easier to use something else. If you're a strong Postgres DBA, I can see how you'd come down on the side of PostgREST. If you're a strong Rails dev, it would make more sense to use that.
  - deleted 4y ago
    [deleted]
  - cpursley 4y ago
    FWIW: https://github.com/supabase-community/supabase-rb https://github.com/supabase-community/supabase-rb
- wharfjumper 4y ago
  I presume you mean postgres client libraries? Or have I missed a postgrest feature?
  - cpursley 4y ago
    Either or. There are a number of server client libraries that work directly with PostgREST: https://postgrest.org/en/stable/ecosystem.html#client-side-libraries https://postgrest.org/en/stable/ecosystem.html#client-side-l...
giraffe_lady 4y ago
It's not necessarily my preference but the last few years a lot of my work has been in systems that are just a thin api wrapper around postgres. In practice the biggest issues with it are that the tooling is significantly behind the state of the art of mainstream dev tooling, both for working engineers and ops. It's also not built with this with style of working in mind, so you accumulate a lot of little struggles that are hard on engineering morale and confidence in the deployed system. DBAs have their own practices, but admin is a different discipline from dev and they aren't always directly compatible. The other problem is that for most modestly sized money-making applications, the database is the single most resource-intensive and expensive necessary part of the stack. Putting a bunch of business logic in there will never help that, and query optimization is a difficult to acquire skill. You pretty much always end up with just a couple of people who can talk the query planner down off a cliff when you get into the shit.

cpursley 4y ago

You can get really far with database views (decorating data, especially), functions (all sorts of biz logic) and Postgres roles for RBAC. But I hear you on integrating with 3rd party APIs, etc. Fwiw, there's a number of PostgREST backend client libraries to help with that.

blowski 4y ago
Totally agree that it's possible. But at some level, it may just be easier to use something else. If you're a strong Postgres DBA, I can see how you'd come down on the side of PostgREST. If you're a strong Rails dev, it would make more sense to use that.
- deleted 4y ago
  [deleted]
- cpursley 4y ago
  FWIW: https://github.com/supabase-community/supabase-rb https://github.com/supabase-community/supabase-rb
wharfjumper 4y ago
I presume you mean postgres client libraries? Or have I missed a postgrest feature?
- cpursley 4y ago
  Either or. There are a number of server client libraries that work directly with PostgREST: https://postgrest.org/en/stable/ecosystem.html#client-side-libraries https://postgrest.org/en/stable/ecosystem.html#client-side-l...

giraffe_lady 4y ago

It's not necessarily my preference but the last few years a lot of my work has been in systems that are just a thin api wrapper around postgres. In practice the biggest issues with it are that the tooling is significantly behind the state of the art of mainstream dev tooling, both for working engineers and ops. It's also not built with this with style of working in mind, so you accumulate a lot of little struggles that are hard on engineering morale and confidence in the deployed system. DBAs have their own practices, but admin is a different discipline from dev and they aren't always directly compatible. The other problem is that for most modestly sized money-making applications, the database is the single most resource-intensive and expensive necessary part of the stack. Putting a bunch of business logic in there will never help that, and query optimization is a difficult to acquire skill. You pretty much always end up with just a couple of people who can talk the query planner down off a cliff when you get into the shit.