3 ms·

I personally strongly dislike GraphQL between internal services. GraphQL is amazing when your service has to respond to unpredictable queries, like with a publ

by 013a 9y ago

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.

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

by 013a 9y ago

adamkl 9y ago

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