Hacker News new | comments | show | ask | jobs | submit login

So at this point it seems we are going back to how software was developed before web. Clients interact directly with database through a query language. In this case GraphQL is an equivalent of SQL and "custom GraphQL resolvers" are an equivalent of stored procedures, triggers and other business logic.

I wonder if we will see databases expose GraphQL access layers directly.




I think eventually that's where all of this is going. We're going to have to figure out how to bolt access control onto GraphQL in a better way than we currently do today but that's certainly a solvable problem.


About access control in context of this article, Hasura gives GraphQL APIs with a role-based-access-control layer that can be integrated with any standard auth system.

https://docs.hasura.io/1.0/graphql/manual/auth/index.html

PS: I work at Hasura


Also AppSync from AWS is a very access-control-first approach to GrapgQL hosting


That's pretty much what we are doing at Hasura, expose Postgres to the client directly with a powerful enough query language on top of GraphQL so that developers can get away with writing as little business logic as possible.

The biggest challenge is access control which we have modeled based on Postgres's RLS but for application users and roles.


FWIW I appreciate the balance hasura is going for re: RLS. I balked at the interfaces I’d have to maintain to get strict pg-user per profile row access. It is nice to have a ramp.


I think your crystal ball is broken. That falls to shit as soon as you need things to work offline. Imagine if the gmail app worked that way - no more checking emails in tunnels.


I wonder if we will get to the point where servers will start exposing sql access layers directly.


I hope so. SQL is better defined, more usable, more complete, and has better access controls than GraphQL. But at the same time I both doubt it, and I think storage structure is the wrong abstraction to expose (and here data-mapped GraphQL is just as bad).





Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: