> is it just "we don't like GraphQL" or something? Yes. But not without reason. GraphQL departs from web standards and semantics in order to solve a problem

> is it just "we don't like GraphQL" or something? Yes. But not without reason. GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs. You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc... This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that. With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design. GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport. Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1]. [1] https://jsonpatch.com/ https://jsonpatch.com/