Sign in Subscribe
By Matthew Reinbold in Newsletter —

Net API Notes for 2019/10/17 - GraphQL in an HTTP/2 Future?

It had been my hope to recap the best bits from last week's API World and API-the-Docs conferences this week. However, Phil Sturgeon swung a tweet at the GraphQL community like a protective parent takes a bat to a beehive.

"GraphQL is anti HTTP/2 by definition."

Let's sort through all the subsequent buzz.

GRAPHQL: PAST, PRESENT, AND HTTP/2 FUTURE

PAST

GraphQL has always been a lightning rod for passionate debate. In 2016, I covered the debate as to whether GraphQL ran counter to quality API design. Almost exactly a year later, I shared my frustration with teams choosing GraphQL not on its merits but because of FOMO (Fear Of Missing Out). After additional coursework and coding, I recapped my impressions on both GraphQL earlier this year.

Bottom-line: the GraphQL time-to-first-hello-world (TTFHW) experience is stellar, there is compelling tooling support. Still, I continue to view it as a tool to be used for specific use cases, rather than the apparent one-and-only API style to be used henceforth and evermore.

PRESENT

What did Phil mean when he said: "GraphQL is anti-HTTP2"?

Earlier this month, I resurfaced the Phil Sturgeon article, "Let's Stop Building Around a Network Hack. Much of the early GraphQL proponents GraphQL's ability to 'reduce network round trips'; rather than having to make multiple net API calls to get the desired information, a GraphQL client can query exactly for the information they need across many sources, all at once. Phil has argued, several times, that this argument is a manufactured strawman.

The touted benefit becomes more suspect in light of HTTP/2. In Mark Nottingham's article "How Multiplexing Changes Your HTTP APIs", Mark goes deep on HTTP/2 and its support for multiplexing or having multiple requests and responses in flight on one connection.

Of course, this goodness in HTTP/2 is also part of HTTP/3. And, as an added benefit, standard HTTP components, especially caches, continue to work. Mark ends his piece by encouraging API designers to create "highly granular HTTP API(s) to meet the needs of your clients" as "the protocol makes them cheap enough to not practically matter".

I get Mark's point, but I'm not about to advocate atomizing a functional monolith. Over-fragmentation of common concepts is still a colossal client comprehension problem. Further, the adoption of HTTP/2 is a WIP. While browsers have been doing this for years, your mileage will vary across your libraries, tools, and servers.

Perhaps the most reasonable, sanguine opinion came from (surprise!) a Canadian. Matt McLarty, in his piece "Why is Everyone So Emotional About GraphQL?" finds a middle ground. He calls for greater understanding and adoption of a toolbox approach.

FUTURE

Vulcain, announced October 11th, replies on HTTP/2 server push to create fast, client-driven REST APIs. As its author, Kévin Dunglas, declared, "you don't need #GraphQL anymore!" It is a compelling project that allows for request-chaining to happen within a single request. The Github readme (which is well written, btw), refers to GraphQL as a "smart network hack".

Even with multiplexing, there is a need for the client to understand which APIs are called in a single request. What Vulcain does is utilize hypermedia, as defined in an OpenAPI document, to define the relationship between items.

Did the hairs stand up on the back of your neck? I know that has Darrel Miller's spider-sense tingling. I hope the name doesn't cause confusion with other projects, like VulcainJS, an "open source microservice framework", though.

Of course, this is all predicated on the assumption that GraphQL's only benefit is saving clients requests over the wire. As Marc-André Giroux points out, this is a bit like saying the only benefit of commercial air-travel is the single-serving snacks. Marc points out that GraphQL:

  • Is highly client-centric

    • the tooling experience is great

    • clients are able to pick and choose what is relevant to them

  • API providers are freed to take a 'kitchen-sink' approach (see above)

  • Allows persisted-queries to be derived over time, driven by real use, rather than guesstimated during design time

Also, GraphQL also supports a form of streaming, without having to resort to websockets.

The value of these statements will vary given your needs and experience. And GraphQL is unlikely to remain fixed. I look forward to covering those new developments.

Are you using GraphQL? With poor query capture support in standard traffic tools like Data Dog and New Relic, what are you using for monitoring? Are you having challenges onboarding endpoints into your existing gateway? Let me know - I'd love to hear how folks are operationalizing this popular, yet debated, approach.

MILESTONES

WRAPPING UP

As mentioned, this week, the ASC conference is happening in Vancouver. If you're looking to attend additional API events in person, check out NetAPI.events. The community is always glad to see you. And if you know of a meetup, hackathon, or conference that should be added, let me know.

Finally, thank you to my Patreons. I appreciate your support for this humble tappy-tappy on my lappie.

Till next time,

Matthew @libel_vox and matthewreinbold.com

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe