Everybody 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.
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.