Rather than looking at generic abstract classes of use (such as "multiple internal clients") I think a more valuable discussion would have been a look at what specific use cases work well for graphql such as answering questions like:
"What products did customer X order last month"
The resolvers for this query are likely easy to create and perform well against most data sources even those with limited support for indexing. They also will likely work nicely even if products and customers are different databases or even database architectures.
Vs use cases where graphql does not work well such as attempts to answer questions like:
"What is the ranking of customer X in terms of our profitability last month?"
If this result is not pre-calculated and if customers, sales, products, and shipping costs come from four different data sources then this can be very tricky and really cannot be answered efficiently.
I fully admit there are ways to work around these potential pain points, but people should know that answering questions like the above can be way harder to answer via GQL than (I at least) expected.
We drank the Cool Aid on our first GQL based implementation without understanding:
1) Cross resolver math is unexpectedly tricky
2) Summarizing data in resolvers is unexpectedly tricky and expensive
3) Sorting and ranking data points is unexpectedly tricky and expensive
4) doing all of the above is crazy difficult compared to what we had been lead to believe.
1 comment
[ 3.4 ms ] story [ 11.0 ms ] thread"What products did customer X order last month"
The resolvers for this query are likely easy to create and perform well against most data sources even those with limited support for indexing. They also will likely work nicely even if products and customers are different databases or even database architectures.
Vs use cases where graphql does not work well such as attempts to answer questions like:
"What is the ranking of customer X in terms of our profitability last month?"
If this result is not pre-calculated and if customers, sales, products, and shipping costs come from four different data sources then this can be very tricky and really cannot be answered efficiently.
I fully admit there are ways to work around these potential pain points, but people should know that answering questions like the above can be way harder to answer via GQL than (I at least) expected.
We drank the Cool Aid on our first GQL based implementation without understanding:
1) Cross resolver math is unexpectedly tricky
2) Summarizing data in resolvers is unexpectedly tricky and expensive
3) Sorting and ranking data points is unexpectedly tricky and expensive
4) doing all of the above is crazy difficult compared to what we had been lead to believe.