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).