quda
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
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 
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.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
cmo
What about
ws://localhost:4000/socket/websocket?quda
Nope, the same.
Why do I have the impression that these “channels” work only with the Phoenix client?!?
LostKobrakai
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.
quda
As suspected… proprietary implementation.
The URL format might be embedded in this “protocol”.
Which is this non-standard message protocol pls ? There can I find the doc ? Tx.
antoine-duchenet
I just tried to connect to
ws://localhost:4000/live/websocketon a brand new Phoenix project and it worked (liveis 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).
LostKobrakai
I’m not sure where you got the expectation from that channels are plain websockets.
Here are the docs on channels (Channels — Phoenix v1.8.8) 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.8.8 and the message format by Phoenix.Socket.Serializer — Phoenix v1.8.8.
If you want to use the existing serializers then you can find them here: phoenix/lib/phoenix/socket/serializers at main · phoenixframework/phoenix · GitHub
The format is negociated on connection.
quda
You’re right, my wrong.
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
LostKobrakai
I mean you could always integrate directly with cowboy. That’s essentially what phoenix does with it’s sockets.
LostKobrakai
@quda here you can find an example, which proxies iex to a browser via websockets: IEx in a Box :: cone.codes
quda
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.