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.
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.
useGETForQueries
And I do understand the advantage of a single request, but the _tradeoff_ in backend development time does seem extreme.
Keen to know if you can expand on trusted client _a richer API_ - what's richer than building your on request from many small endpoints?
With “just” HTTP2, you’d be doing one of the following:
- creating bespoke endpoints
- creating an adhoc GraphQL-like API
- introducing latency equal to the round trip latency multiplied by the number of layers the query is deep
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.