I'm not particularly familiar with GraphQL, but this article highlights a common problem in the promotion of new libraries, patterns or methods. These are usual

I'm not particularly familiar with GraphQL, but this article highlights a common problem in the promotion of new libraries, patterns or methods. These are usually advertised as having a number of independent benefits or solving a series of unrelated issues, but when you look into each of them, it usually turns out that the same advantage can be easily obtained by adopting much smaller changes on top of the current tools. In the end, the question that proponents of a new technology in a team usually avoid addressing is: "what specific problem we have here and now that this new method solves, and why can't this specific problem can't be solved by the simple addition of X to our current solution, without the need to change absolutely everything?" Because even if a new library solves a laundry list of issues, usually the ones that need to be solved in a specific context- the bottlenecks- are just one or two. And those usually can be solved by small incremental changes.