Using Dgraph as a backend for a GraphQL API/Proxy

Users GraphQL
,
1

Greetings,

I’m a little confused about how applications that use dgraph are meant to be architected. Let’s look at the following setup:

[browser] ==graphql==> [API Server] ==graphql==> [dgraph]

In the above case, I would want an API server to handle the incoming graphql server, do authorization checks / job management. Then, the graphql request would need to be proxied/forwarded to the dgraph instance. This is the desired setup as it gives the developer granular control on the API server to analyze the request before hitting the db (dgraph).

From the documentation, it appears that applications are meant to be designed like this:

[browser] ==graphql==> [dgraph server]

There’s a putting it all together which introduces authorization via JWT with some node middleware. But the middleware is extremely light and the authorization is heavily integrated into the dgraph schema. I’m not a fan of this approach.

Are there any resources/blogs/examples on real applications using the former (imo real world) model to design their APIs? I really like dgraph, but seems like just adding a postgres backend would be easier (if less performant).

3 Likes
2

There are some that have been setup like that. If I wasn’t going to use the @auth and was going to build my own GraphQL server, I would use the DQL endpoints instead of the GraphQL endpoint.

There are quite a few better examples now of using Auth0 with the GraphQL endpoint for a complete setup. The @lambda directive can now also handle a lot of business cases.

It might be easier, but you would have to handle then server side caching, remedy the N+1 problem, and make sure you handle the over and under fetching problems. And this doesn’t even begin to start the problems of generating inputs and creating relationships by reference. A SQL database doesn’t make sense behind GraphQL because it is requesting structured data into a flattened table and then parsing that flattened table back out to fit the schema.