[lopatin]

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.

[sheeshkebab]

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.

[RussianCow]

> 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".

[lopatin]

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.

[skc]

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.

[jcroll]

Have you had to maintain the graphql server