While using GraphQL does have some benefits when dealing with a massive amount of users, that's not the reason most people choose to use it. GraphQL is simply a drastically different (and IMO better than REST) model for clients to talk to servers.
I don’t think it is - mutations (and state management) are the biggest issue. It’s ok for reads though, although even there tooling for rest is better.
> I don’t think it is - mutations (and state management) are the biggest issue.
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".
I agree with RussianCow, I don't think mutations are in any way harder in GraphQL than they are in REST.
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.
Well, I tested it by creating a little sample android app that fetched a collection of images for display in a grid.
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.
Well, its a fancier API tool, which smooths out the flow between Backend and API consumers better (at a cost).
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.
I believe it makes life easier for consumers. What about if you have to maintain the api? And if it is that much harder to maintain is it really a smart choice unless the surface area of your api is the size of say Facebook's?
You don’t “need” almost anything, the point of new tools isn’t usually that you need them it’s that they make your life easier.
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.
You are being downvoted but I think it's a pretty legitimate question and the answer to it is: Yes.
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.
> 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.
What is the reasons for a backend service to delegate it’s authentication/authorisation to the graphql in front of it. Making the graphql server a super user for the service
Sounds wrong to me