I hope not. My experience with GraphQL is that it's amazing in the hands of competent developers. When used by a slightly less than average developer, great problems will occur. Regardless, lots will likely jump on this bandwagon.
I've seen bad implementations that use GraphQL like a web based hibernate layer w/ so much waste, the caching layers and "optimizations" end up creating an unmaintainable rube Goldberg machine. SQL optimization can often be avoided, resulting in everything as a key-value fetch and manually "joined."
The fat of the common frameworks and extra layers adds a lot of latency, also. Not a problem with single request scenarios, but can become an issue with more complex apps.
I've also seen front end teams fully rely on the GQL layer to denormalize their data for them and blow 40k requests to 12MB or more. A dedicated backend team as gatekeepers is easier to circumvent, esp if they don't have the experience to debug GQL runtime behavior.
Then, there's the problem that traditional monitoring and acceleration patterns don't work with GQL, operationally, as well as with REST. You need to instrument metrics and monitor externally or parse the request body just to get a sense of what's being requested. GQL is a new black box where bad things can happen in secret, if you don't know how to expose it.
Granted, sane people don't necessarily have all of these problems, but the potential for disaster is much greater. Being that it's relatively new tech, there aren't a lot of resources to guide developers through the pitfalls.
I predict that GQL will earn me quite a few dollars as a consultant, fixing bad implementations.
(Author here) So, I actually mostly agree with you on the dangers. But I also have to ask myself, "is it still a fundamentally better situation?" To me, the answer is yes.
The dangers you point out aren't flaws with the paradigm, but risks for abuse. Completely comparable risks also exist with REST, though.
It's going to take time to develop the same level of sophistication in implementation in the GraphQL world. And I think part of the abuse comes from the way the technology is currently taught. A big part of the reason I wrote the article is because I think GraphQL is the future because of what it actually is, rather than the way people commonly think of it.
In most situations, I think GraphQL is going to lead to more rational API design, if people focus on modeling the what the client needs to tell the server to do rather than building robust query systems with it (unless that's the first-class need).
I've seen bad implementations that use GraphQL like a web based hibernate layer w/ so much waste, the caching layers and "optimizations" end up creating an unmaintainable rube Goldberg machine. SQL optimization can often be avoided, resulting in everything as a key-value fetch and manually "joined."
The fat of the common frameworks and extra layers adds a lot of latency, also. Not a problem with single request scenarios, but can become an issue with more complex apps.
I've also seen front end teams fully rely on the GQL layer to denormalize their data for them and blow 40k requests to 12MB or more. A dedicated backend team as gatekeepers is easier to circumvent, esp if they don't have the experience to debug GQL runtime behavior.
Then, there's the problem that traditional monitoring and acceleration patterns don't work with GQL, operationally, as well as with REST. You need to instrument metrics and monitor externally or parse the request body just to get a sense of what's being requested. GQL is a new black box where bad things can happen in secret, if you don't know how to expose it.
Granted, sane people don't necessarily have all of these problems, but the potential for disaster is much greater. Being that it's relatively new tech, there aren't a lot of resources to guide developers through the pitfalls.
I predict that GQL will earn me quite a few dollars as a consultant, fixing bad implementations.