Are Phoenix channels appropriate for most socket usecases?

tl;dr Brand new to phoenix. I’m creating a discord clone to learn elixir/phoenix.

The basic requirement is for a client to send audio bytes (base64 encoded) over a socket to my server and the server should respond by broadcasting that message out to all the other clients.

I’m wondering if phoenix channels are appropriate because:

  1. All channels (seem) to use the same socket connection. Due to the nature of the requirements I think this particular piece should be handled by a different socket connection (this might be unnecessary. thats just my initial take on it so far).

  2. The message body of the socket contains a lot of phoenix related metadata and structure. I’m wondering what this structure does and how it impacts my application. I’m just paranoid because this socket will be streaming real-time audio. I don’t want its heavy usage to somehow degrade the application.

  3. I plan on using Phoenix Live View in other parts of the application (as part of some generic CRUD interface). I don’t want the quality of that service to degrade because of the real-time audio usage.

Thoughts?

1 Like

Phoenix v1.4 has a low-level socket transport abstraction, so you can run your audio stuff on it: https://hexdocs.pm/phoenix/Phoenix.Socket.Transport.html - in this case there is no metadata nor anything and you can do your own binary protocol on top of JavaScript websocket’s API.

This is also possible with channels by using custom serializers. But if you want a separate socket only for this, then the low-level one may be the way to go.

9 Likes

This is exactly what I was looking for. Thank you!