> What I'm not seeing is how do you ..

You can write fairly complex rules with the access control layer ! The first two conditions are possible (except for the project is only visible on Mondays).

  allow select on rows which satisfy this property: 
  { "project_type" : { "_eq" : "whatever" } }

  allow update on rows which satisfy this property: 
  { "closed_data" : { "_is_null" : true } }

The idea is simple, we provide a boolean expression based access control layer which can use variables from headers. When you can't specify it using the access control layer, you can write this in your own graphql layer and schema stitch with hasura. So you only have to write what is not possible with the access control layer.

> The other point I don't see is how do you ...

You can use the tooling around Postgres ! You can create an `ON INSERT` trigger on the table and listen to these events.

We're launching something very cool in the subscriptions/event-source to solve these kinds of problems. We also have 2 nice projects that work independent of the graphql-engine to help with change subscription on postgres (skor[1], pgdeltastream[2])

[1] https://github.com/hasura/skor [2] https://github.com/hasura/pgdeltastream

> u can write fairly complex rules with the access control layer

Oh, I see. As a suggestion then, many business rules are not tied to roles. You may want to look into some "always enforced rules" or something like that, to avoid having to repeat these rules for each role (and the maintenance nightmare this entails).

> your own graphql layer and schema stitch with hasura

Again, I'm not versed in GraphQL in general, so this is from my ignorance. Maybe you could provide some example/tutorial on "stitching your own GraphQL apis with hasura" (your other examples, posts and tutorials are awesome btw!).

> You can use the tooling around Postgres

Fair enough. I've always found a bit hard to properly manage and test these native features (much harder than managing/testing pure code), but it is a sound solution nonetheless. Maybe you want to hint to these other projects somewhere in hasura's docs (I've checked them and couldn't find it, but maybe I'm just blind/didn't look hard enough).

Again, awesome project and good answers. I can't stop going through possible pet-projects to try this out soon! :)

> Maybe you could provide some example/tutorial on "stitching your own GraphQL apis with hasura"

We have an example of schema stitching in this repo https://github.com/hasura/graphql-schema-stitching-demo

It stitches a weather API schema and a person schema. Hope it gives an idea.

For "access control layer" to work in the general case we need to be able to code it in a real programming language, no? Or are you going for something one-size-fits-many like Sharepoint?

For the latter, GraphQL itself explicitly forbids recursivity [0], as it's impossible to guarantee that in all cases the data isn't infinitely recursive, especially with cyclic queries, which could lead to a denial-of-service. Postgres has its own support for recursive queries [1], however you'd need to strap a pagination layer on top in order to make it work with GraphQL.

[0]: https://github.com/facebook/graphql/issues/91#issuecomment-2...

[1]: https://www.postgresql.org/docs/9.1/static/queries-with.html

What a cop-out. Datomic Pull, which predates Graphql by two years and does not have an impedance mismatch problem, handles recursion perfectly fine. https://docs.datomic.com/on-prem/pull.html#recursive-specifi...

I suppose this can be done with row-based security if you are willing to mirror/maintain this in Postgres and/or fork the query engine to issue them under the right roles. There was a talk at PG Day UK 2018 about this but there are no performance benchmarking results available AFAIK.

As to triggers, you can totally do this with event sourcing in triggers, so when something is modified you write a row to the audit table, and you use another process to read from it and do the right thing, etc.

> The price is only visible for projects of type "whatever".

Tangentially, this one's shockingly common and not something I'd consider silly. Many manufacturers obligate their distribution partners to market only certain prices in order to keep pricing expectations for a certain product at a certain level.