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

wojtekmach
Hey everyone! Req is an HTTP client for Elixir that I’ve been working on for quite some time. There is already a lot of HTTP clients out...
New
handnot2
Samly can be used to enable SAML 2.0 Single Sign On in a Plug/Phoenix application. This library uses Erlang esaml to provide plug enabl...
New
woylie
Flop is an Elixir library that applies filtering, ordering and pagination parameters to your Ecto queries. offset-based pagination with...
New
restlessronin
The repo is at GitHub - cyberchitta/openai_ex: Community maintained Elixir library for OpenAI API · GitHub. Docs are at OpenaiEx User Gu...
152 11030 135
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
fuelen
Hi all! I want to present a small library which provides a mix task for generating an Entity-Relationship Diagram for Ecto schemas. You...
New
woylie
Phoenix components for pagination, sortable tables and filter forms with Flop and (optionally) Ecto. pagination cursor pagination sorta...
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
mudasobwa
I am seeing a lot of aplications of Argumentum ad Vericundiam in software discussions. They do link some piece of writing and point us to...
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
sorenone
Today we’re releasing Oban for Python. Not an Oban client in Python. Not a pythonx wrapper embedded in Elixir. Nope, it’s a fully operati...
New
Herve37
We’re evaluating API mocking tools for OpenAPI-based projects and would love to hear what other teams are using. We’re particularly inte...
New
sergio
It’s not that it’s vocabulary is too advanced. It’s something worse. I get lost trying to follow even a paragraph written by Claude. It’...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews