I would place a bet along with you on that one. The question the graphql folk need to think about is who's paying for the value add of large one hit requests. cycles add up! There's a price to pay for having your api also have to parse and understand a request beyond just fetching the result.

I'd like to bet against you two. ;) I think GraphQL + a REST (JSON RPC) interface will be an optimal balance between developer experience, performance and security. I'm the founder of WunderGraph and we're doing exactly that: https://wundergraph.com/docs/overview/features/json_rpc

I like this approach, a lot.

I strongly believe developers should spend extra labor to ensure users and runtimes don’t waste cycles. I also believe labor or toil that repeats and can be automated, should. This marries both those ideas.

Finally, while thankfully you don’t say “we take security seriously” on your home page (buzzy but in practice usually a security red flag), your docs and baked-in approach show you genuinely do.

Pinged you via the TypeForm.

You’ll still very likely end up with dozens of http REST calls that could be one GraphQL query, hence one http call. Bias alert (I’m the founder), but I believe you should have a look at GraphQL edge caching: https://graphcdn.io

Most probably a non-issue with HTTP2.