If you're providing an API that's well defined and constrained in scope (i.e. a typical CRUD API where you're creating/modifying normalized objects in a non-cha

If you're providing an API that's well defined and constrained in scope (i.e. a typical CRUD API where you're creating/modifying normalized objects in a non-changing object hierarchy), then graphql is usually just a shitload of unnecessary overhead. Examples that come to mind: 1. An internal API where you own all the clients (you own every query; optimize them.) 2. An API that deals with objects where scopes aren't going to vary (i.e. if your clients are fetching the same 6 basic queries every time, you're not getting benefits out of GQL). 3. APIs that are write/update heavy. Every mutation is the same amount of work (or more) that a REST controller would have to deal with, but you have the overhead of the GQL library on top. Basically: everything is just JSON on the wire anyway. Stop paying the overhead penalty of GQL unless you have a zillion clients and a massive object graph that's going to be queried in unpredictable ways. Typical REST libraries make backend code management and structure MUCH cleaner than GQL, with much more obvious points for caching, query optimization, etc.