Phoenix Channels (ws) without frontend

Phoenix Forum Questions / Help
, , , ,
1

I am trying to develop a small websocket API (as a testbed first) but without using the Phoenix frontend (that socket.js). I need it to communicate to any ws client, not related to Elixir/Phoenix, just exchanging json messages.
Of course I started from the standard, ubiquitous tutorial found online, that one with a simple chat, by modifying it:

  • setup Phoenix project – standard install/config, then:
    mix phx.gen.channel room
  • started & tested the Phoenix server installation in the browser – running fine
  • modified endpoint file:
socket "/socket", TestWeb.UserSocket,
  websocket: true,
  longpoll : false
  • user_socket.ex file added in:
    channel("room:*", TestWeb.RoomChannel)
  • All others left default/unmodified

As you see, nothing special…

Further on, as I understood that the channel must work out-of-the-box reply by default to join, I tried to connect with wscat: wscat -c ws://localhost:4000/socket
Result:

error: Unexpected server response: 404 :thinking:

Hmm… something wrong with the url then tried also with: ws://localhost:4000/socket/room and ws://localhost:4000/room… and several other combinations. But got the same result : 404 :rage:
Maybe wscat is faulty… another series of trial connections using another websocket client, but with similar results.
On the server side, Elixir reports:

[debug] ** (Phoenix.Router.NoRouteError) no route found for GET /socket (TestWeb.Router)
    (test 0.1.0) lib/phoenix/router.ex:406: TestWeb.Router.call/2
    ...

Obviously, I’m missing something trivial but fundamental here, but I can’t figure out what it is.
Please help.

1 Like
2

What about ws://localhost:4000/socket/websocket?

2 Likes
3

Nope, the same.
Why do I have the impression that these “channels” work only with the Phoenix client?!?

4

Phoenix channels are “phoenix channels” not “arbitrary websocket messages”. You can use any websocket client you want, but you’ll need to adhere to the message protocol expected by the server as well as lifecycle messages needed.

6 Likes
5

As suspected… proprietary implementation. :face_with_raised_eyebrow:
The URL format might be embedded in this “protocol”.
Which is this non-standard message protocol pls ? There can I find the doc ? Tx.

6

I just tried to connect to ws://localhost:4000/live/websocket on a brand new Phoenix project and it worked (live is the default LiveView socket path, it could have been any other socket path).

As @LostKobrakai said, Channels is not “arbitrary websocket messaging”, it’s mostly a multiplexing / pubsub protocol, built on top of websockets and able to fallback to longpolling. I suppose it could be considered similar to the Socket.IO implementation (you can read more on the socket.io-protocol, not to be confused with the engine.io-protocol, here if interested).

2 Likes
7

I’m not sure where you got the expectation from that channels are plain websockets.

Here are the docs on channels (Channels — Phoenix v1.6.6) and they very plainly state that channels are transport agnostic, with websockets and longpolling being supported out of the box and some additional 3rd party clients.

The transport is driven by Phoenix.Socket.Transport — Phoenix v1.6.6 and the message format by Phoenix.Socket.Serializer — Phoenix v1.6.6.

If you want to use the existing serializers then you can find them here: phoenix/lib/phoenix/socket/serializers at master · phoenixframework/phoenix · GitHub
The format is negociated on connection.

4 Likes
8

You’re right, my wrong. :neutral_face:
I need a standard, open websocket implementation to build my API on top of it. I wanted to do it in Elixir, unfortunately I have to change framework/language

9

I mean you could always integrate directly with cowboy. That’s essentially what phoenix does with it’s sockets.

2 Likes
10

@quda here you can find an example, which proxies iex to a browser via websockets: IEx in a Box :: cone.codes

5 Likes
11

Thank you @LostKobrakai, nice info set you provided.
I will take a look into your example + cowboy websocket implementation but I have the feeling that would be easier and faster for me to drop Elixir for this task and to build it using js/Node, tools that are way more familiar for me.

12

Maybe you can use something like this: GitHub - lyokato/riverside: Elixir Library: Simple WebSocket Server Framework ( Riverside - Plain WebSocket Server Framework for Elixir)

3 Likes
13

@LostKobrakai covered the details perfectly here in how channels work and what’s required. Any client can talk to channels if they can write bits on the wire, and elixir clients exist in the community. Here’s a great one that you can drop in and work with:

https://hexdocs.pm/slipstream/Slipstream.html

7 Likes
14

I’ve successfully built a 3rd party API on top of Phoenix channels. There are a few implementations in other languages that you can see here, Channels — Phoenix v1.6.6

In addition I built a Javascript library that wraps the JS Phoenix channels client to provide a more succinct API to our backend, frontline-client - npm

2 Likes
15

I use phoenix channels as back-end api to call on angular frontend.

You can do one of the following after npm i phoenix

  1. put the user-socket.js file in your angular (whatever frontend you consume api)

  2. import Socket from phoenix - for specific channel implementation

Let me know if this helps.
You can also get a hint of this from here.

Otherwise, i will try to extract a bare bones implementation.

1 Like
16

If you can share the code where you are trying to implement phoenix channels, maybe it helps to debug.
What does join function look like in your case?

17

@entone & @TwistingTwists thanks both but it was not what I was looking for: an agnostic implementation of ws with Phoenix channels. The channels architecture does not allow that, so I have to go at a lower level and build up from there: Plug cowboy → cowboy_websocket. I’ll tackle this another time though.
For the time being I already built a dirty quick solution for my needs on Node.

3 Likes