This is an open question to the comment community, is anyone here making tradeoffs between GraphQL and using HTTP2 for these existing APIs? I'd be really interested to know which way people landed and why.
Well a regular http API is going to be better for caching. Right now I'm only aware of one product that supports caching in graphql but there are hundreds of thousands of CDN nodes around the world that will cache the result of 'GET /product/5'
HTTP2 is great if you have independent requests and want to avoid head of line blocking. I'm not aware of any sort of streaming/partial result capabilities for graphql.
Graphql is great if you want to give a trusted client a richer API and/or if your infrastructure has good ways of handling abusive API users.
If your problem is that getting the data from the API is slow, both GraphQL and HTTP2 solve your problem: HTTP2 allows you to send REST requests faster, both more concurrently and with faster round trip; GraphQL instead allows you to combine all your requests into a single request that takes a single round trip.
GraphQL obviously provides a more complete solution (one request is better than many), but at the cost of a lot of complexity.
This is plainly not true. Web servers are designed to serve concurrent requests. So are databases. HTTP2 drastically improves the networking part of this. GraphQL offers a unified request-response object without needing to combine responses. It provides no guarantees about improved performance, particularly when the solution is automated and there's no way for a requester to reason about the performance implication of the queries they're issuing. It almost certainly provides worse performance than well designed RESTful endpoints requested concurrently.