Is GraphQL Still Relevant in an HTTP2 World?
From the linked article:<p>&gt; <i>With all of those caveats noted, HTTP&#x2F;2 should put to rest any notion of the need to minimise the number of requests for APIs; the protocol makes them cheap enough to not practically matter. Go ahead and design a highly granular HTTP API to meet the needs of your clients</i><p>This seems highly misleading and missing the point. Sure, you can send a lot of requests in parallel with http&#x2F;2. But you still incur significant latency if these multiple requests are dependent on one another and serialized. For instance, suppose you have 2 granular APIs that:<p>- Returns all friends for the specific user<p>- Returns the name, age and hometown for a specific user<p>Suppose your client wants to get all of a user&#x27;s friends whose hometown is NYC. Even with http&#x2F;2, it has to use the first API, wait for the response containing a list of userIDs, then use the second API to get all of their hometowns.<p>Whereas with GraphQL, it facilitates building a single API call that says &quot;give me all friends for a specific user, along with each friend&#x27;s hometown&quot;. Now, there is only one round-trip latency cost. Not two. Even with the overhead improvements mentioned, the cost of two back-to-back round-trips would be much higher. It is very odd that this isn&#x27;t mentioned in the article or any of the other articles they reference.