GraphQL does not care about the network layer and can operate on http or websocket. It is a query language for your api. Usually there is one http entry point where You send queries and mutations, and socket support for subscriptions.

Loading data for your SPA does not require websocket at all… loading data for your SPA is usually done from the client, with an ajax request.

Websocket are needed when You want the server to act on the client (bidirectional) like pushing new data. But an API client does not require this because it can initiate a query when needed, usually by fetch, or axios.

That is why LiveView and the likes requires websocket to push new data on the client.

Forgive the pedantic nature of this response, I’m going to try and be very precise in my use of terminology.

Absinthe accepts GraphQL documents - query, mutation, and subscription documents - and helps you generate the result of those queries through an Elixir API. It is agnostic about how the document makes it to that API. For subscription documents, where results of the query can be generated asynchronously and/or over time, Absinthe requires a PubSub system and will deliver those results to that system.

The aspects of providing GraphQL documents to Absinthe over the network is handled by software that is outside of Absinthe proper. One popular choice is absinthe_plug which helps to create a Plug pipeline for submitting GraphQL documents to Absinthe. absinthe_plug supports HTTP GET and POST requests. It can also be used to set up an HTTP endpoint that delivers a GraphiQL interface.

To my knowledge absinthe_plug doesn’t do much to help you get the long running results of subscription documents. If you just want to use absinthe_plug your application will still have to provide a compatible PubSub system and find some way to deliver the results of the subscription as they are published by Absinthe.

absinthe_phoenix is a network delivery toolkit for handling GraphQL queries through Phoenix Channels. Those channels, in turn, are currently built on top of web sockets or long polling. Because Phoenix itself includes a PubSub system, absinthe_phoenix can make use of that system to deliver the asynchronous results of subscriptions through a Phoenix Channel (in addition to the synchronous results of query and mutation documents).