I just use GraphQL and freeze the queries at compile time so only known queries can be used. That stops worries about misuse from the frontend. On the backend,

I just use GraphQL and freeze the queries at compile time so only known queries can be used. That stops worries about misuse from the frontend. On the backend, for performance we have two choices: 1. Over-fetch. It's relatively cheap doing that from a cache. Most queries don't use too many different variations. 2. Optimize what data we fetch based on the node's children in the GraphQL query received. I don't think people do this often enough but... GraphQL gives you the full query as an AST, so you can use that at runtime to know what your node's children will be rendering before they're hit. Because we enforce #1, we don't have to build some general-purpose query-builder a simple check of "Are you X named query?" is good enough. Internally it looks kind of like JSON RPC. Am I doing it wrong? It seems to give you the best of both worlds because GraphQL APIs have great tooling and documentation behind them, and if you cut out all the 'general' purpose aspects in production you can be fairly efficient (e.g. our GraphQL API is about 5% slower than the JSON API it replaced).