GraphQL treats HTTP as a dumb pipe. All semantically relevant information is encoded in the GraphQL messages, and none of the HTTP metadata is relevant to the query posed by the client or the response returned by the server.
In theory, this allows the same processor to be used over alternative transport mechanisms and paradigms (e.g., over MQTT or Kafka topics) without adapting the messages themselves to the transport.
> "In theory, this allows the same processor to be used over alternative transport mechanisms and paradigms (e.g., over MQTT or Kafka topics) without adapting the messages themselves to the transport."
This is something that doesn't get mentioned often/a lot of people don't grasp. It's transport agnostic, and this means you can do GraphQL over high performance transports if you have the requirements.
Recent HN top post by Dan Luu: "In defense of simple architectures" discusses how they do this
> "Some areas where we’re happy with our choices even though they may not sound like the simplest feasible solution are with our API, where we use GraphQL, with our transport protocols, where we had a custom protocol for a while, and our host management, where we use Kubernetes. For our transport protocols, we used to use a custom protocol that runs on top of UDP, with an SMS and USSD fallback, for the performance reasons described in this talk. With the rollout of HTTP/3, we’ve been able to replace our custom protocol with HTTP/3 and we generally only need USSD for events like the recent internet shutdowns in Mali)."
> "As for using GraphQL, we believe the pros outweigh the cons for us:"
In theory, this allows the same processor to be used over alternative transport mechanisms and paradigms (e.g., over MQTT or Kafka topics) without adapting the messages themselves to the transport.