Do we need a next generation of web frameworks to take benefit of dgraph?

[cocodrino]

thanks guy, yes one of my doubt was if you intended that many of the requests to the db, which are commonly made by a web framework, could be substituted to be done directly from the client side

have an authorization system answer this question but also I think that in many case we would need some layer between client/db and I’m not sure which could be the best approach here, for instance, suppose that I need validate that a new user password follow some specifications, create a web server that expose a graphql mutation, handle the resolver and then…if everything is ok then pass to dgraph, seems a bit cumbersome,

I’ve found some related questions

Graphql interface with auth

It’s not specifically for Dgraph, but some of its principles or approach might be applicable as folks dig in. I’ve been writing a package for directive-based, fine-grained access control to use with neo4j-graphql-js that modifies filter arguments in the GraphQL query document AST to ensure connection to an arbitrary ACL path – could be extended to any GraphQL backend that uses a similar “filter” argument API. My git repository is: imkleats/neo4j-graphql-deepauth. I lay out the more general AST…

Using Dgraph in a Golang server running a GraphQL endpoint

Hey @Mikeal Using the native GraphQL implementation would be the recommended solution as long as the generated APIs fulfill your needs. If the GraphQL API had authentication/authorization built in to it, would that be good enough for your use case or is there something else that you’d require to be able to use it?

Gary post a link with some shield library which works as a middleware, which could be a good solution for these cases