
Is GraphQL the Future? - acjohnson55
http://artsy.github.io/blog/2018/05/08/is-graphql-the-future/
======
mailslot
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.

~~~
acjohnson55
(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).

