[haack]

It's refreshing that the author acknowledges the nuances around tradeoffs of using, and not using, GraphQL.

Having used REST (with swagger/openAPI), gRPC and now graphQL, the most painful thing has been the tribal militance from supporters of each, defending their own vested interest.

It's almost like different tools are useful for different things.

[jakenberg]

> tribal militance from supporters of each, defending their own vested interest.

This is something I really wish I understood before going down the road of graphql. I think it's a great technology, but the developers supporting it are making it nearly impossible for a legacy codebase to ever adopt.

Ex: so many JS codebases use redux. Apollo is a popular graphql framework that supported redux integration for some time, then suddenly ripped it out. They cited performance concerns, but I looked through the code myself and it would seem they just have a bias against redux. This issue thread makes that especially evident: https://github.com/apollographql/apollo-client/issues/2273

We were very lucky to have found that before breaking ground on the work.

[ledauphin]

Which is ironic because Apollo 2.0's caching mechanisms have some very serious performance issues themselves, and they take almost all the power away from the user (unless you want to implement your own cache from scratch).

[Dockson]

I believe one of the main selling points of the upcoming 3.0 version is indeed to make the cache more usable with manual evictions, etc.