Now, if you combined this with a good RBAC security model, particularly if you baked that model into the GraphQL -> SQL conversion layer, so it sends SQL queries that work on an allowed subset.. that'd be very cool.
The security mechanisms in Firebase might serve as an inspiration :)
What would you like to see? (PG dev here)
No defensiveness, no push back, just a prompt to start a conversation with a potential user to better their product. :)
Just like PG, we based security in Neo on role-based access. Users have roles, those roles then have permissions to do lots of cool things.
What we should have done, had we had infinite time (and to be clear: it was the correct choice to build a role-based system given the constraints, I just wish there'd be more time in a day..), was to build a resource-based system; instead of roles, you have graphs of direct and delegated privileges over specific resources; resource-based access control.
If I build an app today, I don't want to say "Users can edit x,y,z columns on the comments table". I want to say "Users can edit x,y,z columns on the comments table, if they were the ones that wrote them and the comment does not have a lock flag".
The bulk of web app code today, for small to mid-sized apps anyway, is about dealing with this resource control. Which is ridiculous - imagine how many CPU cycles are spent on secondary queries to look up ownership hierarchies from dumb ORMs. There's no good reason that couldn't be modeled at the level of, or below, the query planner, having it simply design the query plans to abide by the per-user access constraints.
The cost of that would be massively higher than what the planner does today - but looking at the performance of the whole system, it'd be amazing.
This is, kind of, what Firebase does, right - it rolls resource-based access control into its query planner, combined with good federated user management.
GRANT UPDATE (subject, text) ON comments TO user;
CREATE POLICY comments_update_own_not_locked ON comments FOR UPDATE TO user
USING (locked IS NOT TRUE AND created_by = current_setting('postgrest.claims.username'))
WITH CHECK (created_by = current_setting('postgrest.claims.username'));
Row-level security in Postgres is awesome!
That's exactly what I wanted.
I guess it's true as they say, that the easiest way to get the right answer on the internet is to publish the wrong answer :)
We are currently developing a security model for http://graph.cool that sounds very similar to what you describe wanting for Neo4j. If you have time I would love to show it to you and get your feedback (email in profile).
You mention the security model of Firebase as an example to emulate. Unfortunately firebase only allows permission rules to consider path elements to the data, so in reality it actually ends up being fairly restricted and difficult to maintain.