[bsbechtel]

I lot of the issues you mentioned really are meant to address problems faced by teams working on a project at scale. I really didn't understand the need for GraphQL until I was put on a project where we had multiple REST endpoints we needed to query data from, new people were joining every week, and communication + data requests across different teams required a significant portion of everyone's time.

The issues you mentioned are issues if you want one (or a few) framework or library to handle all of your web development needs, but rarely does one library work for web development at scale.

[sbacic]

It sounds like your issue was with poor documentation and not some fault inherent to REST itself. I don't think that just switching to GraphQL is going to fix that problem (though Playground is a pretty nice way of getting to know the API).

I guess my main qualm was that, because GraphQL does a relatively poor job of explaining why you should use it, people like me get the wrong idea about what kind of problems it solves and why you should use it instead of REST.

[bsbechtel]

It's not really an issue with documentation within our team. It's an issue of having hundreds of REST endpoints (all which need to be learned by new devs), multiple local dev servers running on your machine to mimic those endpoints, and an excess of work done on the front end to merge data from across those REST endpoints once it all arrives on the client. Additionally we would get requests from other teams wanting to access data, so instead of them just writing a query to the same GQL endpoint we all share, we have to write a new endpoint for them, manage access control on that endpoint, etc. These are the issues GQL solves.