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

Hi guys, I found this article pretty cool

dgraph can handle queries directly without requiring a framework in the middle, but at the same time I think that a framework is still necessary for security reasons, I’ve doubts about how would be the right approach to create an graphql API in any framework, where you can add a security layer without unnecessary duplicate codes or loss some performance benefits of handling the queries directly with dgraph,

do you have any sample, maybe with go or any other language, that you consider follow the best practices and handle graphql queries (not rest)???

for me a framework here would become in some kind of middleware, checking if the query passes directly to dgraph or fails (for instance requesting an unauthorized data)

thank you so much

With Dgraph you don’t need to create any GraphQL API by hand. It is all automated based on your Schema. Read

You can implement Auth in your schema
BTW, Dgraph has a REST API for GraphQL+- (This is Dgraph’s lang, it has nothing to do with GraphQL itself). The Dgraph’s GraphQL API just uses HTTP methods as any GraphQL implementation. The blog post mention a way (using Postman) to do dev things in your server. It (Dgraph’s GraphQL) isn’t “REST” per se.

What Framework (Apollo? relay?) do you have in mind? I was a bit confused about this reading your question.


1 Like

Also, I have seen more security features are being added such as ip whitelisting certain endpoints and adding additional tokenized security within these endpoints to prevent any un authorized actions.

For even extra layers of security, I have recently added traefik rules for even more control.

1 Like

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

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

There has been some talk about modifying the custom directive to work with possibly dgraph queries and even more excitingly, native javascript.i like the javascript hinted at idea because then we can write an almost limitless amount of logic to any field, query, or mutation. And I hope this becomes a reality :crossed_fingers:


that would be awesome…thanks for share that…

I was also into the architecture stack of view last week.

If in 20.07.0 we have custom resolver to external endpoint (which is more crucial than ‘having custom code inside dgraph’), it will be solved a lot of doubt.