You probably don't need GraphQL

GraphQL is one of the most annoying developer inventions ever made. I have never found a good use for GraphQL even at huge scale.

I'm sure Facebook has some use for it, but even then, you can still add filters with good ol' RESTful APIs.

And the fact that you can never just get back the entire response, you have to purposefully specify every item you want is beyond annoying for practical use.

It's useless added complexity. I wish it would go away. Unfortunately, technology ebbs and flows in hype cycles, where when something gets popular or is made by a giant technology corporation, the herd of developers and PMs and tech leads think they must follow suit. No one is asking "why are we doing this?" They want to look good by using the "latest tech" and are too timid and too inept to understand why adding shiny new technology to everything might not always make sense.

Luckily GraphQL is starting to go out of fashion. Now I have to deal with PMs wanting to add "AI" to everything. It's like trying to appease cattle.

> The problems that GraphQL solves

> 1. Mobile apps break periodically after API changes

The author says that GraphQL solves this problem because GraphQL APIs never contain breaking changes (the author phrases it slightly differently). I disagree: breaking changes happen when you don't have proper diligence and review of changes. I've seen breaking changes happen in GraphQL and REST APIs, and they are always because people didn't consider how their changes would break the clients - it had nothing to do with the engine powering the API. I'm not strongly anti-GraphQL, but I don't believe that you will avoid breaking API changes just by adopting it.

Granted, one might argue that my experience is with people who were "doing GraphQL wrong". Well, no disagreement there, but it reinforces my point that a protocol or language won't protect you from human error.