Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening a single socket to pass messages through #25

Closed
Gastove opened this issue Dec 17, 2014 · 4 comments
Closed

Opening a single socket to pass messages through #25

Gastove opened this issue Dec 17, 2014 · 4 comments

Comments

@Gastove
Copy link

Gastove commented Dec 17, 2014

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
Copy link
Owner

jarohen commented Dec 18, 2014

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
Copy link
Author

Gastove commented Dec 18, 2014

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
#25 (comment)
.

@Gastove
Copy link
Author

Gastove commented Dec 18, 2014

(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
#25 (comment)
.

@jarohen
Copy link
Owner

jarohen commented Dec 18, 2014

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

@jarohen jarohen closed this as completed Jan 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants