ChannelClient

Channel client for connecting to Phoenix Channels from Elixir.

Rework from phoenix_client library.

Installation

Add channel_client and a json library as dependencies in your mix.exs file. jason is specified as the default json library.

def deps do
[
{:channel_client, "~> 0.12"},
{:jason, "~> 1.4"}
]
end

If you choose to use a different json library, you can set it through the socket options with the :json_library key (or its alias, :serializer).

Usage

There are two things required to connect to a phoenix server using channels, a ChannelClient.Socket and a ChannelClient.Channel. The socket establishes the connection to the remote socket. The channel takes a topic and is used to join a remote channel. In the following example we will assume that we are attempting to communicate with a locally running phoenix server with a RoomChannel with the topic room:lobby configured to route to the RoomChannel in the UserSocket.

First, Lets create a client socket:

{:ok, socket} = ChannelClient.Socket.start_link(url: "ws://localhost:4000/socket/websocket")

The socket will automatically attempt to connect when it starts. If the socket becomes disconnected, it will attempt to reconnect automatically, and by default every joined channel is re-joined on the new connection (see Reconnections). Joining blocks until the connection is up, so you do not need to poll ChannelClient.Socket.connected?/1 first.

Next, we will create a client channel and join the remote.

{:ok, _response, channel} = ChannelClient.Channel.join(socket, "rooms:lobby")

Now that we have successfully joined the channel, we are ready to push and receive new messages. Pushing a message can be done synchronously or asynchronously. If you require a reply, or want to institute a time out, you can call push. If you do not require a response, you can call push_async.

In this example, we will assume the server channel has the following handle_in callbacks:

def handle_in("new:msg", message, socket) do
{:reply, {:ok, message}, socket}
end
def handle_in("new:msg_async", _message, socket) do
{:noreply, socket}
end
message = %{hello: :world}
{:ok, ^message} = ChannelClient.Channel.push(channel, "new:msg", message)
:ok = ChannelClient.Channel.push_async(channel, "new:msg_async", message)

push/4 returns {:ok, response} when the server replies with an ok status, and {:error, reason} for everything else (server error replies, timeouts, unencodable payloads). It never raises or exits.

Messages that are pushed or broadcasted to the client channel will be sent to the pid that called join. Messages will be of the of the struct %ChannelClient.Message{}.

In this example we will assume the server channel has the following handle_in callback

def handle_in("new:msg", message, socket) do
push(socket, "incoming:msg", message)
{:reply, :ok, socket}
end
message = %{hello: :world}
{:ok, ^message} = ChannelClient.Channel.push(channel, "new:msg", message)
flush
%ChannelClient.Message{
channel_pid: #PID<0.186.0>,
event: "incoming:msg",
payload: %{"hello" => "world"},
ref: nil,
topic: "room:lobby"
}

Replies that arrive without a matching synchronous push (for example replies to push_async) are forwarded to the joining process as %ChannelClient.Message{} structs with the event "phx_reply".

Event handlers

If you prefer callbacks over mailbox pattern matching, pass a handler/1 fun to join. It receives every %Message{} for the topic and runs inside the channel process (crashes in it are logged, never propagated):

handler = fn %ChannelClient.Message{event: event, payload: payload} ->
IO.puts("#{event}: #{inspect(payload)}")
end
{:ok, _response, channel} =
ChannelClient.Channel.join(socket, "rooms:lobby", %{}, 5_000, handler)

Wire formats

JSON is the default, but the format layer is pluggable. ETF (Erlang terms), TOON and BTOON ship built in:

{:ok, socket} =
ChannelClient.Socket.start_link(url: "ws://localhost:4000/socket/websocket", format: :etf)
# TOON/BTOON delegate to {:toon_ex, "~> 1.5"} (optional dependency):
{:ok, socket} = ChannelClient.Socket.start_link(url: "...", format: :toon)
{:ok, socket} = ChannelClient.Socket.start_link(url: "...", format: :btoon)

Custom formats (MessagePack, protobufs, ...) implement the ChannelClient.Format behaviour and plug in with format: MyApp.MsgPack. Legacy options (:vsn, :json_library, :serializer) keep working. See the Formats guide.

Pluggable architecture

Sockets support Plug-style middleware for messages, in two pipelines:

{:ok, socket} =
ChannelClient.Socket.start_link(
url: "ws://localhost:4000/socket/websocket",
inbound_plugs: [
{ChannelClient.Plugs.FilterEvents, events: ["presence_diff"]}
],
outbound_plugs: [
fn msg, _opts -> {:cont, %{msg | payload: Map.put(msg.payload || %{}, "sent_at", DateTime.utc_now())}} end
]
)

A plug is a module using ChannelClient.Plug (write just call/2, or add your own init/1) or a plain fun/2. It returns {:cont, message} to pass the message along (optionally transformed) or {:halt, reason} to block it — halted outbound frames surface as errors to sync callers, halted inbound frames never reach your processes. Faulty plugs are logged and treated as halts; they cannot crash the socket.

Built-ins ship under ChannelClient.Plugs (Logger, FilterEvents). See the Plugs guide for the full walkthrough.

Telemetry & tracing

Every connection, message and channel operation emits standard :telemetry events, including start/stop/exception span triples you can feed straight into dashboards or tracing backends:

:telemetry.attach(
"my-handler",
[:channel_client, :push, :stop],
fn _name, %{duration: d}, meta, _ ->
Logger.debug("push #{meta.event} -> #{meta.result}")
end,
nil
)

Payload contents are never included in event metadata. See the Telemetry guide for the full event catalog.

Reconnections

When the underlying connection drops, the socket reconnects automatically and re-joins every topic it was subscribed to (rejoin?: true, the default). Delivery simply resumes — callers need no re-join logic. Failed rejoins are reported to the channel's owner as a %ChannelClient.Message{} with event "phx_error".

With rejoin?: false, channels are unregistered on disconnect instead and each joining process receives a %ChannelClient.Message{} with event "phx_close" (clean close) or "phx_error". Callers are expected to react by joining again once the socket reports connected through ChannelClient.Socket.connected?/1.

While connected, the socket sends Phoenix protocol heartbeats every heartbeat_interval ms (default 30_000) so servers keep the connection open; set it to :infinity to disable.

Both :text and :binary WebSocket frames are supported for inbound messages.

Common configuration

You can configure the socket to be started in your main application supervisor. Pass :name (and optionally :id) inline so it can be referenced from your channel:

socket_opts =
Application.get_env(:channel_client, :socket)
children = [
{ChannelClient.Socket, Keyword.merge(socket_opts, name: ChannelClient.Socket)}
]

You will need a socket for each server you are connecting to. Here is an example for connecting to multiple remote servers.

socket_1_opts =
Application.get_env(:channel_client, :socket_1)
socket_2_opts =
Application.get_env(:channel_client, :socket_2)
children = [
{ChannelClient.Socket, Keyword.merge(socket_1_opts, name: :socket_1)},
{ChannelClient.Socket, Keyword.merge(socket_2_opts, name: :socket_2)}
]

Channels are usually constructed in a process such as a GenServer. Here is an example of how this is typically used.

defmodule MyApp.Worker do
use GenServer
alias ChannelClient.{Socket, Channel, Message}
# start_link ...
def init(_opts) do
{:ok, _response, channel} = Channel.join(Socket, "room:lobby")
{:ok, %{
channel: channel
}}
end
# do some work, call `Channel.push` ...
def handle_info(%Message{event: "incoming:msg", payload: payload}, state) do
IO.puts "Incoming Message: #{inspect payload}"
{:noreply, state}
end
end

License

Apache-2.0. Based on the original phoenix_client work.