[accountantbob]

I'm helping to move a big 10B per year ecommerce site to graphql. This lack of tooling support around graphql (vs REST) is a big minus currently.

Some examples: CDN is a big one that you mention. Our vendor (the biggest in the industry) has no support for GraphQL beyond what they do for REST or html pages. We've talked about moving the query into the path or as a parameter but then we have to figure out how to determine what can be cached. With REST it is easy: cache /sku, /product, etc but never /guest, /order, etc.

Tools that do performance monitoring (AppDyn, datadog, etc) don't grok GraphQL well. Quick example is response codes. What's the http status code of a graph response that has a partial failure? If you make it 200, then those tools won't see any errors. We put the error codes in the response body and those tools aren't parsing that for message failures.

[guiriduro]

Our case is similar, albeit smaller, and we're only at the stage of considering the next step (from static, webpacked JSON.) Our application relies on several regionalised hefty product+metadata JSON files. Data changes, while infrequent (~2 per week), involve republishing. Especially for the (recently-added) mobile app, large downloads are a UX issue. Changes aren't easily isolated by file segregation, and can cross-cut, although of course we're looking at the right level of granularity (we do have a product hierarchy and price dimension.) The apps already rely on REST for a smaller part of their dynamic functionality, so providing the main bulk through CDN-cached REST is an option; GraphQL was superficially attractive but the CDN issues are a showstopper for adopting it, for now.

[filleokus]

>Tools that do performance monitoring (AppDyn, datadog, etc) don't grok GraphQL well.

If you haven't seen Apollo Engine[0], you might want to checkit out. Maybe its too expensive or problematic in some way for your scale, but I've used it quite successfully (on a much smaller scale). You implement their status-format for your responses, and place a proxy between your graphql server and client requests, which then siphons of the status data to them.

Regarding CDN, it would be interesting to see if someone tries to do some "computing on the edge" (i.e Cloudflare workers) to calculate/modify cache info from the graphql response.

EDIT: Apparently Apollo have a proposed standard for indicating cache status inside of responses[1], which then Engine can use to calculate correct cache headers for the CDN.

[0]: https://www.apollographql.com/engine [1]: https://github.com/apollographql/apollo-cache-control

[kentonv]

The Apollo people have a prototype of Apollo Server running on top of Cloudflare Workers, at the edge: https://github.com/jbaxleyiii/apollo-server-cloudflare

(Disclosure: I'm the tech lead for Workers at Cloudflare.)