>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.
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.
[1]https://github.com/avantcredit/gql2ts [2]https://github.com/apollographql/apollo-codegen [3]https://github.com/Shopify/graphql_java_gen