Thanks for the episode on websockets. Right now I'm using SSE for notifications (in yada). Yesterday I ported them to websockets. Don't know if this was a good idea or not, but with yada + manifold this was only a couple of lines difference.
I've heard that some companies block websockets in their firewals, so SSE may be the safer choice if you only need 1 direction, although SSE can hit the connection limit if users open up your app in multiple tabs.
@borkdude Interesting point. I've never tried SSE. Cool to hear that it was only a few lines change to switch. Makes it easier to switch back if you do run into problems.
yeah. with manifold / aleph and SSE was returning a core async channel. If I wrote something to the async channel, it would turn up in the browser as an event. the change to websockets was simply to use the websocket API from manifold and connect it to the very same channel I had earlier:
(fn [ctx]
(let [req (:request ctx)
conn (http/websocket-connection req)
user-id (auth/user-id (user-profile ctx))
sse (:dre.app.sse/sse system)
chan (sse/new-chan-for-user! sse user-id)
_ (-> conn (d/chain
(fn [socket]
(s/connect chan socket)))
(d/catch (fn [e]
(error e))))]
(sse/send-message-to-user sse user-id :sse/ack)
{}))
Firewall blocking is a good case for using a framework that can fall back, like sente.
I'd rather implement the fallback myself so I have more control over it I think
Good point.
this was the same function for SSE:
(fn [ctx]
(let [sse (:dre.app.sse/sse system)
user-id (auth/user-id (user-profile ctx))
chan (sse/new-chan-for-user! sse user-id)]
(sse/send-message-to-user sse user-id :sse/ack)
chan))
Very cool.