the-mikedavis

the-mikedavis

We @ NFIBrokerage use websockets and Phoenix.Channels fairly extensively in production, serving well over 100k connections a week.

When we first started using websockets broadly between back-end services, we noticed an odd build-up of process memory in Phoenix.Channel server processes which we now presume to be a product of moving large amounts of data over-the-wire and a known issue in :websocket_client (see more in the Slipstream documentation). This and the at-the-time archival of the popular phoenix_gen_socket_client led us to write a new Phoenix.Channel client from scratch backed by :gun.

Enter Slipstream!

Slipstream touts

  • :gun under the hood
  • reconnect and rejoin mechanisms with back-off similar to phoenix.js
  • a rich set of :telemetry events
  • utilities for testing clients similar to Phoenix.ChannelTest
  • a GenServer-like callback interface for client modules with default implemementations for all callbacks
  • a synchronous interface for scripting
  • an ever-expanding examples directory with reference clients and tutorials

After cutting over the bulk of our socket clients to Slipstream, we’ve seen a marked decline in clients disconnecting from Phoenix.Channels as a result of the server disconnecting them (as opposed to the client gracefully disconnecting).

(That line at 02/02 13:20 marks the mass cutover. Note that the other disconnection reasons than “disconnected by remote server” are expected and are considered normal and desirable behavior. Remainders of “disconnection by remote server” denote deploys and restarts of services running Phoenix.Channels. Also note that this improvement is more likely an indirect result of switching to :gun: that the remote server has less memory pressure and is therefore more reliable, rather than a hypothetical bug in the :websocket_client implemementation which would force disconnects.)

We’ve been using slipstream widely in production for a little while now and want to share it with y’all! If you’re in the market for a new Phoenix.Channel client, look no further.

https://github.com/NFIBrokerage/slipstream

Showing Posts 1 to 5

jamesvl

jamesvl

This looks really great! Thanks for open sourcing this; I hope to get some time soon to try it out locally in one of my projects that also relies quite heavily on websockets.

the-mikedavis

the-mikedavis OP

Slipstream v0.8.0 has been released!

v0.8.0 switches out :gun for Mint.WebSocket as the low-level WebSocket client.

Gun is great but its strict dependencies on cowlib often conflict with cowboy’s (and therefore Phoenix), making it hard to use gun in a Phoenix project without an override.

Check out the CHANGELOG for extended notes on the changes and how to upgrade.

10
Post #2
andarotajo

andarotajo

Hope it’s okay to dig up this thread. I’m very new to Elixir and looking for a WebSocket client library. Slipstream looks pretty good but I’m wondering about the Phoenix part.

Looking at the examples there’s no Phoenix involved so my question is: Does this library actually require Phoenix or can I use it standalone?

lawik

lawik

Nerves Core Team

Slipstream inplements Phoenix Channels which is a specific implementation on top of WebSockets.

For raw WebSockets you can check what Slipstream depends on over at hex.pm. There should be a websocket library in there.

LostKobrakai

LostKobrakai

mint web socket might be a little too low level, but there are other general purpose websocket clients on hex as well.

— All posts loaded —

Where Next? Top

Trending in Announcing Top

type1fool
WebAuthnLiveComponent WebAuthnComponents See this post about renaming the package. Passwordless authentication for Phoenix LiveView app...
New
GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
woylie
I released Doggo, a collection of unstyled Phoenix components. https://github.com/woylie/doggo Features Unstyled Phoenix components....
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
ahamez
Hi everyone, I’ve been working on this protobuf library for 3 years. We use it in the company I work for, EasyMile, to communicate with ...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
kip
I’ll shortly be launching Text, a nascent text analysis library. Current functionality In this early version (not ready for prime time) ...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
bartblast
Hey folks, I just published a post about Hologram’s funding and where the project goes next - the short version: Curiosum as Main Spons...
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews