Slash GraphQL Architecture -- OR -- What Path Does My HTTP Query Go Down?

I had sent an email request regarding the “middle layers” of Slash GraphQL, it was a high-level overview of the differences between the requested path for data in Slash GraphQL VS if I simply deployed my own instances of the Dgraph on a big Ditro (AWS). Obviously, Slash GraphQL provides a web client to interface with so a user can write schemas and do admin. This suggests to me an intermediary server between the DB and the backend-as-a-service (Dgraph).

Thinking about the additional layers of technology between an http request to Slash GraphQL and how it gets routed to the Dgraph service and what kind of stack / layers my request goes through to hit a DB and return my request. In a traditional API, you might first hit a gateway, then some controller logic, and then some kind of transformation (in another API or language like SQL) to access the DB. That best case scenario for this last bit of the data path is your are NOT using an additional http call but something like GRPC or sockets to have fast connection on a lower protocol (TCP/IP) between your API controller and DB.

When I compare a possible competitor of Slash GraphQL — FaunaDB — who also provide a cloud managed UI to write native GrapahQL / create Schemas and auto-generate your CRUD resolvers (and manage scale, redundancy, auth, etc) — there is a “gotcha” because that service is meant to be consumed as a DB only. So even if you write a custom resolver, it is scoped to the DB’s domain and cannot call outside to micro-services. This means you cannot use Fauna as a backend in cases where you need to call other services. Instead, you must create a traditional API in front of Fauna to handle controller logic and micro services. You therefore lose any of the cool “just write GraphQL” advantages of that being the native query language to the DB because you are forced to do an initial http request to your API and then an other http request to Fauna. Although you get the nice dev experience of native GrpahQL, it comes at the cost of adding and an additional layer between your first http request and your db by way of a second http request.

With all that said, I wanted to better understand the path my http request takes to Slash GrpahQL and if there more layers — especially less performant transformations — between this initial http request and the actual DB.

Having a deep understanding of the path my http request flows to/from and from the DB would be much appreciated.

A good diagram and infographic comparing services would also be a great way to educate those interested.


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

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.