GraphQL + gPRC

Users GraphQL
,
1

For the next generation of @custom, it would be nice to support gRPC calls/messages over http/2. More efficient/performant I’d say - and coherent with respect to dgraph itself.

2

I have had this idea of supporting GraphQL over gRPC for a long time, had written down some initial thoughts about how I would want to use it, but never worked on it :sweat_smile:

Let me paste my thought content here, better get some feedback in advance:

gRPC + GraphQL lib

  • two ways:
    • one /graphql gRPC endpoint that has got only one Server streaming RPC call which has the same I/O as GraphQL HTTP req/response
      • Query/Mutation: send only one message for them in the response stream
      • Subscriptions: send multiple messages in a never ending response stream
        • How to cancel them? should the call be a Bi-Directional streaming RPC? Because there has to be an unsubscribe callback from the client?
      • Pros:
        • Implementation in full conformance to the spec
        • GraphQL still behaves just as a QL (but over gRPC), which is what the aim of GraphQL is.
        • Having Protobufs for serialization improves the network usage (but just a bit)
      • Cons:
        • Although it feels like it is now GraphQL over gRPC, but doesn’t really use the full features of it.
        • The performance won’t be as good as what it could have been. We have all the static info available the moment we have the schema defined. But, we are not making use of it. If we do, we can save a lot more network bandwidth with Protobuf serialization.
        • There is only one RPC call, while there could have been a proper client gRPC API with one RPC call per query/mutation/subscription. That would have made input validation inbuilt into the client and the server. No more parsing of the request.
    • one /graphql gRPC endpoint that has got many RPC calls, one each for a query/mutation/subscription. The I/O of each RPC call will be similar to whatever the I/O of the corresponding query/mutation/subscription is.
      • Query/Mutation: one unary RPC call per query/mutation.
      • Subscription: one Server/Bidirectional streaming RPC call per subscription.
      • How to convey selection set to the server?
        • What about the arguments which a field in the selection set may have?
        • fragments?
        • unions? - oneOf
        • __typename
      • introspection?
      • Pros:
        • Makes full usage of all the static info available, which will result in better serialization with Protobufs, and hence better performance over the network.
        • The client API generated will be more elegant and easy to use. Really uses gRPC features.
        • Auto-generated introspection response. But, really of no use. Because there is a beautiful client API already.
      • Cons:
        • Not easy to build.
        • May go breaking for clients as soon as you change the schema, as it may change the proto definitions.
        • Not spec compliant. GraphQL is no more used as a QL in this case, but just as a concept. But, we can still call it a tooling around GraphQL :slight_smile:

Please Vote

  • Which of the two ways would you prefer?