I’m about to try integrating websockets into a yada handler. Are there any gotchas I should be aware of? I know Sente has support for Aleph so I was just going to go the Sente route as a first attempt

@oliver.mooney we use the aleph websocket support and a ring handler - it's lower-level than yada, but it's straightforward and operates happily alongside other yada handlers

@mccraigmccraig good to know, thanks

@oliverm I used server sent events, it was painless with yada / aleph

(why do you have two accounts…, I don’t know which one to at)

If you want to know more, google for the yada chat application

How I use it: I send a small message to the client that something should be updated. Then the client does the request to the server using the same logic that was already in place in Re-frame, etc. No special code needed

And all of the auth still works.

@borkdude thanks, I was thinking of using SSE for broadcasts but you use it to ping a particular client to pull updates from the server? Do your clients use normal http methods to return data to the server, so no websockets at all?

Sorry about the two accounts, a previous job required me to make a separate one that’s now derelict :face_with_rolling_eyes:

yeah, I ping particular clients.

hmm that could work really well, thanks for the pointer

just store the channel(s) (plural if you want to support multiple open tabs) per client in an atom somewhere, by user-id

and then choose those, doseq over them and put a message in them

seems super straightforward, great

yeah, note that you also have to deal with closed channel when the user closes a tab, but you’ll figure it out

SSE is significantly superior to WebSockets for most things. King of them is that authorization works, and you don't need to develop your own scheme on top.

Games are the only use case that need the low latency that WS provides, as far as I know. Maybe chat too @mccraigmccraig? But you would need to convince me 😊

There's an example of using websockets in Edge (https://github.com/juxt/edge). We use it to do Graphql subscriptions, mostly because the Graphiql console is more mature for WS although we could have made it work with SSE too. You can use thr Authorisation header when upgrading the protocol to WS.

i’ve no idea what the sse latency is like @dominicm but unless it’s pretty bad it will probably be fine for chat... websockets were pretty trivial to implement tho, auth & all

one nice thing about the websocket api - it’s a bi-directional socket, so the client can keep on sending messages to modify what the server end is doing - we use this to subscribe and unsubscribe a user’s websocket to different topics of interest as the user moves around in the app

My information is apparently incorrect with regards to authentication.