View Source Absinthe.GraphqlWS.Transport (AbsintheGrahqlWS v0.3.6)

Handles messages coming into the socket from clients (implemented in handle_in/2) as well as messages coming from within Elixir/Absinthe (implemented in handle_info/2).

If the optional Absinthe.GraphqlWS.Socket.handle_message/2 callback is implemented on the socket, then messages that are not specifically caught by handle_info/2 in this module will be passed through to Absinthe.GraphqlWS.Socket.handle_message/2.

Note: This module is not intended for use by individuals integrating this library into their codebase, but is documented to help understand the intentions of the code.

Link to this section Summary

Functions

Generally this will only receive :pong messages in response to our keepalive ping messages. Client-side websocket libraries handle these control frames automatically in order to adhere to the spec, so unless a customer is writing their own low-level websocket it should be handled for them.

Receive messages from clients. We expect all incoming messages to be JSON encoded text, so if something else comes in we blow up.

Callbacks for parsed JSON payloads coming in from a client.

Receive messages from inside the house.

Subscribe messages in graphql-ws may include a subscription, implying a subscription to a long term stream of data. These messages may also be queries or mutations, so do not require a stream.

Process was stopped.

Link to this section Types

Link to this section Functions

Link to this function

handle_control(message, socket)

View Source
@spec handle_control(
  {term(), [{:opcode, control()}]},
  socket()
) :: reply_inbound()

Generally this will only receive :pong messages in response to our keepalive ping messages. Client-side websocket libraries handle these control frames automatically in order to adhere to the spec, so unless a customer is writing their own low-level websocket it should be handled for them.

@spec handle_in(
  {binary(), [{:opcode, :text}]},
  socket()
) :: reply_inbound()

Receive messages from clients. We expect all incoming messages to be JSON encoded text, so if something else comes in we blow up.

Link to this function

handle_inbound(message, socket)

View Source
@spec handle_inbound(map(), socket()) :: reply_inbound()

Callbacks for parsed JSON payloads coming in from a client.

See: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md

Link to this function

handle_info(message, socket)

View Source
@spec handle_info(term(), socket()) :: reply_message()

Receive messages from inside the house.

  • :keepalive - Regularly send messages with opcode of 0x09, ie :ping. The graphql-ws library has a strong opinion that it does not want to implement client-side keepalive, so in order to keep the websocket from closing we need to send it messages.

  • subscription:data - After we subscribe to an Absinthe subscription, we may receive messages for the relevant subscription. The graphql-ws will have sent us an id along with the subscription query, so we need to map our internal topic back to that id in order for the client to figure out what to do with our message.

  • :complete - If we get a query or a mutation on the websocket, we're supposed to reply with a Next message followed by a Complete message. We follow through on the latter by putting a message on our process queue.

  • fallthrough - If c:Absinthe.GraphqlWs.Socket.handle_message/2 is defined on the socket, then uncaught messages will be sent there.

Link to this function

handle_subscribe(payload, id, socket)

View Source

Subscribe messages in graphql-ws may include a subscription, implying a subscription to a long term stream of data. These messages may also be queries or mutations, so do not require a stream.

Link to this function

pipeline(schema, options)

View Source
Link to this function

terminate(reason, socket)

View Source
@spec terminate(term(), socket()) :: :ok

Process was stopped.