Is GraphQL Still Relevant in an HTTP2 World?

For more context: https://apisyouwonthate.com/blog/lets-stop-building-apis-around-a-network-hack

GraphQL: A Single Request to Rule Them All

Part of the appeal for GraphQL is that it helps us deal with those expensive HTTP/1 connections better. That’s because GraphQL lets client select every single possibility exposed by the server within a single round trip. Compare this with a hypermedia focused API, which usually requires a lot of network requests (Something caching can help with).

https://graphql.org/ uses this as a “selling” point.

Gotcha: It’s still early days for both HTTP/2 clients and certain application servers

This one is not a good excuse but it is worth mentioning. Using HTTP/2 at the application layer is far from a solved problem in some ecosystems. I’ll let you google for Rack/Rails over HTTP/2, it’s quite something. This is because a lot of application servers have been built with the request/response pattern, and starting to think in terms of those HTTP/2 streams is not an easy task, especially for certain frameworks. But, it’s not a good excuse, a lot of ecosystems do support it well, and in theory, we should still aim to make this better! (Most proxy servers do support it though, but it’s hard to do things like server pushes if the app server is stuck in that req/response pattern.)

GraphQL is not only about reducing round trips or about over/under-fetching

While we see these two things being advertised a ton, GraphQL gives us a lot more than the ability to reduce round trips, or to reduce the number of bytes transmitted over the network.

Our REST API, while very capable of handling the requests from our devices in a generic way, is optimized for none of them.

Notice that this isn’t necessarily about REST needing us to make more requests, or transmitting unnecessary data. It is more about designing an API that enables support for multiple and different client use cases. A common way to handle this problem is to let client logic be ran closer to the server, like Netflix’s client adapters mentionned in that 2012 post. Since then, some teams there have even been using GraphQL. The BFF pattern is another abstraction that aims to solve similar issues.

The Client Developer Experience

I tend to focus a lot on server side stuff in these posts, but it’s important to remind ourselves that GraphQL is especially loved at the client level! GraphQL fragments are an absolutely awesome abstraction when paired with the component pattern we see in modern frontend frameworks. Again, paired with persisted queries, the GraphQL client developer experience can be quite incredible.

It’s the Whole Package that Makes it Great

GraphQL isn’t inherently special, and yes alternatives will exist! Typed schema? Just use OpenAPI! Server-side abstraction to handle multiple client use cases? There are many ways to do that. Introspection? Hypermedia can allow clients to discover actions and can start from the root too. The amazing GraphiQL? I’m sure there’s something for OpenAPI. It’s always possible to recreate parts of what GraphQL has. However, it’s everything together, found under one specification that made GraphQL appealing and great to so many of us. I suspect that’s also what made it grow so fast also. Because there’s so much guidance into building this API style, language specific libraries for GraphQL tend to be high quality and well adopted.

The Network is Still (will always be?) A Constraint

Here’s a last thought. No matter how fast network requests will be, it seems like they will always remain some sort of constraint. This is why we don’t design web APIs like typical programming language objects for example:

Snippet from Patterns of Enterprise Application Architecture: https://martinfowler.com/books/eaa.html

Can HTTP/2 help GraphQL?

OK so GraphQL brings us tons of other important things, but HTTP/2 is still really awesome. Something to possibly look at in the future is if we can bring some of this power to GraphQL too. Something like this:

query {
viewer {
name
posts(first: 100) @stream {
title
}
}
}

Final Words

HTTP/2 is awesome, and the example in this article in particular is quite mind blowing! And if GraphQL is simply a way to reduce the number of round trips you’re making, or about saving bytes, chances are you’ll be happy with an HTTP/2 powered endpoint-based API! However If you’ve also felt the other powers we’ve discussed in this article, you probably also realize that GraphQL brings us much more than this.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marc-André Giroux

Marc-André Giroux

#GraphQL Enthusiast, Speaker, Senior Software Developer @ Netflix 📖 Book is now available https://book.productionreadygraphql.com/