Using an alternate websocket javascript client

[Myron Marston]

Our phoenix usage thus far has just been as simple JSON API.  Now we're getting started building some new app features using channels.  The javascript client phoenix ships with is very nice, but the UI devs (who work in a completely different codebase) would prefer to use a more generic web socket client (such as https://github.com/socketio/engine.io-client).  The UI team writes code that interfaces with multiple backend services maintained by separate teams using different server-side languages, and they expect to use websockets for communication with some of our non-phoenix backends.  As such, they would prefer to use a generic websocket client rather than the phoenix one.  I think this is a reasonable idea but it's obviously a tradeoff.  So, a few questions:

1. Does the phoenix server assume a phoenix-specific websocket client or can it talk with a generic websocket client out of the box?  If it assumes the client speaks phoenix, what is required for an alternate client to conform?
2. Will future changes to the communication patterns between phoenix and its clients be called out in changelogs so we know what changes are needed to the client when we upgrade phoenix in the future?
3. Is there anything significant we're giving up by using a generic client besides an API that matches phoenix's model (topics, etc)?
4. Any gotchas we should be aware of?
5. Is there any documentation around what is required of a phoenix channel client?

Thanks!

Myron

[Chris McCord]

You cannot use another client like socket.io, because Phoenix channels and socketio use different messaging protocols. My recommendation is so use the phoenix.js client and continue to build great things with it :)

Other answers inline:

1. Does the phoenix server assume a phoenix-specific websocket client or can it talk with a generic websocket client out of the box?  If it assumes the client speaks phoenix, what is required for an alternate client to conform?

Yes. You need to use a client that abides by the transport contract:

https://github.com/phoenixframework/phoenix/blob/master/lib/phoenix/socket/transport.ex

1. Will future changes to the communication patterns between phoenix and its clients be called out in changelogs so we know what changes are needed to the client when we upgrade phoenix in the future?

Yes, always.

1. Is there anything significant we're giving up by using a generic client besides an API that matches phoenix's model (topics, etc)?

Yes, if you wanted to go with a bare WS connection, you'd need to handle the following off the top of my head:

1. client connection recovery

2. routing traffic (topics + events)

3. multiplexing server processes on a single concrete connection (channels)

4. client crash notification/recovery when a process on the server crashes

5. Maybe: support for more than WS transport, such as long polling fallback

6. PubSub integration on the server

7. origin checking

1. Is there any documentation around what is required of a phoenix channel client?

https://github.com/phoenixframework/phoenix/blob/master/lib/phoenix/socket/transport.ex

--
You received this message because you are subscribed to the Google Groups "phoenix-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenix-talk...@googlegroups.com.
To post to this group, send email to phoeni...@googlegroups.com.
Visit this group at https://groups.google.com/group/phoenix-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-talk/3be8bb96-4d30-4490-bd05-48ebbefb1b0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Myron Marston]

Thanks for the detailed answer, Chris!