Opening a single socket to pass messages through

[Gastove]

Hello! This is a "how does your awesome library work" question, not a bug or an issue. So:

I have single-repo Clojure server with a ClojureScript front-end. All the routes are Compojure in the server; the server, then, needs to be able to respond to a set of routes by passing data in to the client so it can respond correctly.

What I imagine doing, then, is having a single route for the client to hit to open its socket, then a handler on the server for routes that need to pass messages. Something like;

;; Server
(defroutes app-routes
  (GET "/ws" [] somehow-return-a-web-socket)
  (GET "/api/:foo [foo]" (pass-message-through-socket foo))
  (GET "/api/auth/:bar" [bar] (pass-message-through-socket bar)))

The client opens a go-loop on "/ws", then listens to whatever is dispatched through it. What I can't tell is: does chord support this? If so, what would somehow-return-a-web-socket look like? (The other option I see is to have every route that needs to talk to the client open a different socket, and on the client listen to all of them using alts! -- but somehow I find that less... pleasing.)

[jarohen]

Yes - Chord supports this (in fact, it's the main use-case :) )

You can wrap the handler with the chord.http-kit/wrap-websocket-handler middleware, which puts a :ws-channel key into the request map. So your handler would look something like this:

(:require [chord.http-kit :refer [wrap-websocket-handler]])

(defroutes app-routes
  (GET "/ws" []
    (-> (fn [{:keys [ws-channel] :as req}]
          ;; do what you like with the WS here, e.g.: 
          (go-loop []
            (if-let [msg (a/<! ws-channel)]
              (handle-msg! msg)
              (handle-close!))))

        (wrap-websocket-handler))))

In your example above, it looks like you might need access to the websocket connection(s) from other routes, so you'll probably have to consider how your routes behave given certain websocket states (i.e. what happens if no-one's connected to the websocket, or what happens if more than one person is connected, etc). If you'd like help on how to structure this, let me know :) I've got an example application along these lines that I haven't yet open-sourced (but really should!), will post a link here.

James

[Gastove]

Oh man. I would love some guidance on how to structure something like this -- websockets are a liiiittle new to me ;-P There's no rush, but if you get around to posting a sample project here, I'd be much obliged.

Thanks!

On Thu, Dec 18, 2014 at 4:02 AM, James Henderson notifications@github.com wrote:

Yes - Chord supports this (in fact, it's the main use-case :) )

You can wrap the handler with the chord.http-kit/wrap-websocket-handler middleware, which puts a :ws-channel key into the request map. So your handler would look something like this:

(:require [chord.http-kit :refer [wrap-websocket-handler]])

(defroutes app-routes (GET "/ws" [] (-> (fn [{:keys [ws-channel] :as req}] ;; do what you like with the WS here, e.g.: (go-loop [](if-let [msg %28a/<! ws-channel%29] %28handle-msg! msg%29 %28handle-close!%29)))

    (wrap-websocket-handler))))

In your example above, it looks like you might need access to the websocket connection(s) from other routes, so you'll probably have to consider how your routes behave given certain websocket states (i.e. what happens if no-one's connected to the websocket, or what happens if more than one person is connected, etc). If you'd like help on how to structure this, let me know :) I've got an example application along these lines that I haven't yet open-sourced (but really should!), will post a link here.

James

— Reply to this email directly or view it on GitHub https://github.com/james-henderson/chord/issues/25#issuecomment-67476887 .

[Gastove]

(My inclination has been to store an identifier in the :session of a given request, and use that to try and keep track of who-gets-what in the multiple user case. Maybe there's a more sophisticated way to handle that, though?)

On Thu, Dec 18, 2014 at 7:26 AM, Ross Donaldson gastove@gmail.com wrote:

Oh man. I would love some guidance on how to structure something like this -- websockets are a liiiittle new to me ;-P There's no rush, but if you get around to posting a sample project here, I'd be much obliged.

Thanks!

On Thu, Dec 18, 2014 at 4:02 AM, James Henderson <notifications@github.com

wrote:

Yes - Chord supports this (in fact, it's the main use-case :) )

You can wrap the handler with the chord.http-kit/wrap-websocket-handler middleware, which puts a :ws-channel key into the request map. So your handler would look something like this:

(:require [chord.http-kit :refer [wrap-websocket-handler]])

(defroutes app-routes (GET "/ws" [] (-> (fn [{:keys [ws-channel] :as req}] ;; do what you like with the WS here, e.g.: (go-loop [](if-let [msg %28a/<! ws-channel%29] %28handle-msg! msg%29 %28handle-close!%29)))

    (wrap-websocket-handler))))

In your example above, it looks like you might need access to the websocket connection(s) from other routes, so you'll probably have to consider how your routes behave given certain websocket states (i.e. what happens if no-one's connected to the websocket, or what happens if more than one person is connected, etc). If you'd like help on how to structure this, let me know :) I've got an example application along these lines that I haven't yet open-sourced (but really should!), will post a link here.

James

— Reply to this email directly or view it on GitHub https://github.com/james-henderson/chord/issues/25#issuecomment-67476887 .

[jarohen]

Hi Ross - the example project repo is up at https://github.com/james-henderson/flow-chord-demo. I was meant to use it for a live demo for my talk at ClojureX but unfortunately couldn't find a good way to include it :/

The semantics here are that any number of clients can connect to the websocket route - each of them subscribes to a channel of updates that the routes close over. Other clients can then PUT to other HTTP routes, and any updates are echoed out to anyone who happens to be subscribed at the time. I'm making heavy use of core.async's 'mults' - splitting a channel so that many consumers can read from one channel.

Let me know if this is similar to your use case, or if you have any questions :)

James