This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-16
Channels
- # aws-lambda (1)
- # bangalore-clj (2)
- # beginners (121)
- # boot (23)
- # cljs-dev (165)
- # cljsrn (8)
- # clojars (2)
- # clojure (164)
- # clojure-berlin (6)
- # clojure-chicago (3)
- # clojure-italy (5)
- # clojure-nl (1)
- # clojure-russia (4)
- # clojure-serbia (32)
- # clojure-sg (1)
- # clojure-spec (8)
- # clojure-uk (55)
- # clojurescript (94)
- # cursive (21)
- # datomic (30)
- # events (1)
- # hoplon (6)
- # jobs (1)
- # keechma (1)
- # liberator (2)
- # luminus (8)
- # off-topic (48)
- # om (12)
- # onyx (24)
- # parinfer (15)
- # pedestal (8)
- # re-frame (4)
- # sql (18)
- # test-check (31)
- # unrepl (70)
- # untangled (21)
Is there a general strategy for streaming intermittent data that's compatible with use of interceptors? I'm looking for the best way to handle GraphQL subscriptions, where we want to periodically put a blob of JSON into the response (probably driven by a core.async channel). But at the point where this executes, there's a couple of other interceptors on the stack that should be involved. Looking at http://pedestal.io/reference/streaming my best bet may be to return a callback function and stream the content, but them I'm duplicating a bunch of logic that (in the normal, non-subscription case) is inside a couple of interceptors .. .things like choosing a status code, and converting from Clojure data to JSON. Thoughts?
The SSE code would be good, but is not compatible with GraphQL clients, which simply expect the stream of JSON blobs.
And I also would like to know when the client closes the connection, so that we can do some cleanup.
Digging deeper ... looks like web sockets are a valid approach for GraphQL subscriptions.
hlship: try to push for the open issue about ws to be fixed (reported in february). Atm it might allow 8 slow ws consumer or producer to exhaust/lock the async go threadpool (blocking IO in async/go blocks issues). Basically a potential DOS issue.