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.