3 ms·
GraphQL for RPC is an interesting approach. What do you see as the disadvantages? It'd seem to me that not all services can be neatly represented as a 'graph',
by Sirupsen 9y ago
GraphQL for RPC is an interesting approach. What do you see as the disadvantages? It'd seem to me that not all services can be neatly represented as a 'graph', which gRPC works well for. Have you run into this?
- the_duke 9y agoHow you model a GraphQL schema is up to you. You can just treat it as a realitvely flat, rest-like schema that does not have much in terms of graph relations. The Graph in GraphQL is mostly optional.
- adamkl 9y agoExactly!
- adamkl 9y agoEverybody focuses on the “graph” aspect of GraphQL (obviously), but at its core, GraphQL let’s you define methods with input types and return types in the same fashion as you would with any other RPC framework. If you define your methods and types independently of each other (i.e. without any sort of graph or relationship) I don’t see how it’s any different than SOAP/XML or gRPC. The bonus comes with graph/query capabilities that come layered on top. We’re basically exposing our canonical domain model (broken down into microservices by bounded context, and stitched back together to present a unified model), and at the same time, we should have no problem handling more RPC styled requests (e.g. sendNotificationEmail()) when necessary. This approach was a bit of a revelation for us, but we haven’t really seen anyone else out there doing the same thing, so I hope we aren’t barking up the wrong tree.