We were looking at an architecture exactly like this (GraphQL front end, backed by gRPC microservices), because we liked the strongly typed interfaces of gRPC, and the flexibility of GraphQL, but we ran into some technology issues (http/2 support in our PaaS) that made it a non-starter.
We found that we could get the same benefits (minus the performance of gRPC) by just using GraphQL for all of our microservices, and dynamically stitching them together with Apollo’s graphql-tools[1].
We’re really high on the approach because it lets us develop independent services, each with a strongly typed interface, and then mix and match them into a single GraphQL interface on the fly.
It’s been gaining a lot of traction internally at my company. We even put together a “create-react-app” for GraphQL so our teams can easily spin up new services.
I personally strongly dislike GraphQL between internal services.
GraphQL is amazing when your service has to respond to unpredictable queries, like with a public API. But if the queries can be predicted, like in-between services, you lose a lot of database performance by opening your service up to literally any query pattern imaginable. Specifically; nested graphql queries traveling along edges of your data graph will inevitably span multiple tables, but actually implementing it with a single database join is practically difficult, if not impossible in many cases.
GraphQL also doesn't play well with strongly typed languages. Its completely fundamental to how GraphQL works. Your best, safest bet is to have pre-written queries with types associated with those queries, but at that point its questionable exactly what benefit you're getting from GraphQL.
There are practically no mature GraphQL frameworks out there. In practice, Apollo is pretty good, though its incredible to me that you're already using schema-stitching in a production app when it was released just a month or two ago. We're not about to force services to adopt Node just for Apollo. There are a few other promising GraphQL servers in other languages, but none are at the point where they feel production hardened.
>GraphQL is amazing when your service has to respond to unpredictable queries, like with a public API. But if the queries can be predicted, like in-between services, you lose a lot of database performance by opening your service up to literally any query pattern imaginable.
I agree that you have to be careful when it comes to performance, but ultimately, that has to be balanced with the needs of the internal environment. One-off RPC interfaces are easy to set up between systems, but can lack the flexibility to adapt to the requirements of unknown future consumers (I'm thinking large enterprise with multiple lines-of-business). This can lead to a lot of rework and regression testing in the best case, or multiple copy/paste variations with minor differences in the worst.
>GraphQL also doesn't play well with strongly typed languages. Its completely fundamental to how GraphQL works. Your best, safest bet is to have pre-written queries with types associated with those queries, but at that point its questionable exactly what benefit you're getting from GraphQL.
I'm not sure I follow you here. GraphQL's schema definition and introspection capabilities are very similar to SOAP/XML and WSDL's, and those play very well with typed languages. Its possible to generate type definitions off the GraphQL schemas to use on the server side to ensure compile time safety, and there are multiple libraries that will do the same on the client side. [1][2][3]
As for the benefit, flexibility of consumption. Again, I'm thinking enterprise scale where services have long lifespans, and the consumers aren't always known in advance.
>its incredible to me that you're already using schema-stitching in a production app when it was released just a month or two ago
Nothing in production yet. An approach like this will definitely have to be vetted more thoroughly before it gets to that point.
>We're not about to force services to adopt Node just for Apollo
Only required for the schema-stitching layer. The individual GraphQL services can be developed with any language/platform that has an implementation.
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?
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.
We found that we could get the same benefits (minus the performance of gRPC) by just using GraphQL for all of our microservices, and dynamically stitching them together with Apollo’s graphql-tools[1].
We’re really high on the approach because it lets us develop independent services, each with a strongly typed interface, and then mix and match them into a single GraphQL interface on the fly.
It’s been gaining a lot of traction internally at my company. We even put together a “create-react-app” for GraphQL so our teams can easily spin up new services.
[1] https://www.apollographql.com/docs/graphql-tools/schema-stit...