How so? I don't think GraphQL mutations are any worse than their REST equivalents, especially once you get more complex than "update these fields on this entity".
IDK what you mean re: state management. That sounds like a client side concern, nothing to do with the protocol used to communicate with the server.
Additionally, in my experience, the client-side tooling is better for GraphQL, despite it being around for only a fraction of the time of REST. In fact, that's why I chose GraphQL for my projects. I wanted the tooling (Relay, Apollo) that works out of the box with GraphQL, and requires hacks to get it work with REST.
For some reason I found this very simple scenario quite a hassle using a native GraphQL client for Android. And the alternative, ditching the client and making simple http requests was rather clunky when poking around what's returned.
Admittedly I only spent an hour or so on it but...REST just seems drastically simpler to get up and running with.
At its core, it is a project based around a _consumer facing schema_, that can be queried. You put in upfront and ongoing be work to give product/frontend/clients the ability to discuss data requirements around a first-class schema, and then once the resolvers are written, allow them to explore/experiment with the data, in queries that can be used directly in production.
From what I have seen, the first (only?) ones to feel the pain it solves for are Product/Frontend/Clients.
Hopefully that ^ waves away some of the haze
Apollo Client makes a lot of things about frontend apps easier, which is possible because of the well-defined and typed interface that graphql enforces. No, you don’t need it, and there are other ways (like maybe using Swagger) that you could get similar typing for a REST interface. But, FWIW I’m not familiar with any tools that are quite as comprehensive as Apollo out of the box that don’t use graphql.
If you want to have a united interface to multiple services behind the scenes and incorporate ACL or any kind of top-level resource management, GraphQL is a great way to go about doing that.
I like GraphQL outside of these points as well because it's more opinionated than REST. It means you can get on with things instead of having long disagreements about what is and isn't RESTful.