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
@type control() :: Absinthe.GraphqlWS.Socket.control()
@type reply_inbound() :: Absinthe.GraphqlWS.Socket.reply_inbound()
@type reply_message() :: Absinthe.GraphqlWS.Socket.reply_message()
@type socket() :: Absinthe.GraphqlWS.Socket.t()
Link to this section Functions
@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.
@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
@spec handle_info(term(), socket()) :: reply_message()
Receive messages from inside the house.
:keepalive
- Regularly send messages with opcode of0x09
, ie:ping
. Thegraphql-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. Thegraphql-ws
will have sent us anid
along with the subscription query, so we need to map our internal topic back to thatid
in order for the client to figure out what to do with our message.:complete
- If we get aquery
or amutation
on the websocket, we're supposed to reply with aNext
message followed by aComplete
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.
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.