This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-12
Channels
- # announcements (3)
- # babashka (6)
- # beginners (84)
- # biff (1)
- # cider (7)
- # cljsrn (1)
- # clojure (18)
- # clojure-australia (3)
- # clojure-dev (21)
- # clojure-france (1)
- # clojure-spec (6)
- # clojurescript (78)
- # datomic (34)
- # emacs (5)
- # exercism (32)
- # graalvm (1)
- # helix (2)
- # hyperfiddle (3)
- # lsp (36)
- # malli (4)
- # missionary (3)
- # off-topic (54)
- # re-frame (14)
- # releases (2)
- # sql (31)
- # vim (9)
I'm not sure if I'm just missing it but none of the example sente apps seem to touch on websocket subscriptions. I'd like ws clients to be able to send i.e. {:subscribe {:article 14}}
and get all future updates for that key until they unsubscribe. What's the best way to go about doing that?
I think this highly depends on your requirements / needs. We use lacinia subscriptions at work, which work really well since we're using GraphQL either way.
I've explored subscriptions a bit here: https://github.com/RutledgePaulV/websocket-layer
@U5RCSJ6BB How would you handle broadcasts? I've been trying to work out sente because I like the long polling fallback which 'just works' but it's quite obtuse and the examples aren't that easy to follow.
yeah sente has always seemed over-complicated to me. that library i shared has an atom that tracks all the currently attached sockets, so for broadcast you can deref the atom to get the current sockets and send messages to them as you see fit (on the outbound channel). I didn't provide any functions to make that easy and suppose I could have
actually, now that i look at it again, what i intended for broadcast was that you would keep your own atom, and when you receive a subscription message you would add the subscribed channel into the atom that represents your broadcast group. Then whenever you need to broadcast a message you just send it to all the channels in that atom. That way clients can unsubscribe and that sort of thing. just make sure to prune channels from the atom if it's closed when you write to it or attach an on-close callback to the channel that does that
Yeah that's basically what I'm looking for, I want a user to be able to subscribe to i.e. 'profile/14' (compound key) and get updates for that specific item.
I guess I can just use my webserver to handle authentication? (I don't really know much about Websockets in general)
IIRC they're started just like any other HTTP request so I can assign permissions to them based on the bearer token in the initial request?
That's correct. It's common to authenticate the upgrade request (which is just a http request) and close over the user's authentication at that point in time to refer to in subsequent websocket messages. Just be thoughtful about how you handle logout and whether you may want to revalidate the authentication on each frame somehow
Does this ring a bell? java.lang.IllegalStateException: Attempting to call unbound fn: #'my/fn
Where the invoker to my/fn
is just below it, so I can assume it successfully compiled my/fn
There isn't much magic going on the ns other than binding [*ns* ...
which might have to do?
I made a silly typo which was causing my issue, sorry for the noise
...If you're tremendously curious:
I removed my
in a deftest via the following fixture
(remove-ns ns-sym)
(dosync (alter @#'clojure.core/*loaded-libs* disj ns-sym))
But I made a typo in ns-sym
, should have been 'foo
not 'my