Hi Shawn,
Thanks for the question, and welcome to the Dgraph community.
The main benefit of Dgraph of having native graphql support is exactly what you’ve described in your post. The GraphQL query does not hop from app to app until it’s resolved, Dgraph handles the request.
Slash is actually a pretty thin layer on top of Dgraph’s and it’s native GraphQL capabilities. While you can interact with the web client to set up a schema or run queries, APIs requests go directly to the slash graphql instance, which is at your-app.us-east-1.aws.cloud.dgraph.io.
There is not much that happens to requests between your browser and when Dgraph picks it up. Your request hits a load balancer, followed by a proxy layer, which forwards the request over to Dgraph.
The proxy layer does not touch the request or response in a /graphql query, in order to remain fast. It does look at some request/response metadata in order to aggregate statistics which we use for billing, and to figure out if the instance is under a lot of load, and if it needs to scale (something we are working on currently).
The proxy layer does also do a lot of security stuff. Specifically it locks down routes like /admin or /admin to ensure that a rogue HTTP request can’t shut down your slash graphql instance.
We are using Amazon ALB, Amazon EKS, and Nginx as our ingress, so I’d say the overall latency that the Slash GraphQL ecosystem adds (on top of Dgraph) should not be significant.
Tejas