This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-02
Channels
- # announcements (1)
- # architecture (1)
- # aws (21)
- # babashka (37)
- # beginners (173)
- # boot (12)
- # chlorine-clover (5)
- # cider (36)
- # clara (11)
- # clj-kondo (25)
- # clojure (128)
- # clojure-europe (7)
- # clojure-finland (3)
- # clojure-germany (2)
- # clojure-nl (57)
- # clojure-uk (23)
- # clojurescript (71)
- # clojurex (1)
- # core-async (30)
- # core-typed (5)
- # cursive (35)
- # datomic (8)
- # duct (4)
- # emacs (8)
- # exercism (41)
- # fulcro (116)
- # jackdaw (4)
- # jobs-discuss (6)
- # juxt (4)
- # kaocha (16)
- # leiningen (14)
- # malli (5)
- # observability (4)
- # off-topic (2)
- # pathom (19)
- # pedestal (29)
- # re-frame (64)
- # reitit (18)
- # ring (8)
- # shadow-cljs (3)
- # sql (13)
- # tools-deps (32)
- # tree-sitter (5)
- # yada (17)
what are the maintainers' views on functions that don't directly wrap kafka/kstreams functionality living in the library? i've taken a look through the streams.clj
file, it looks like it MAY be an intentionally light wrapper around kstreams.
some background: for one of our kstreams apps we have a util function call divert?
that'll push off a record if a given predicate is true (i.e. to a failure topic, etc):
(defn divert? [stream pred topic]
(let [[divert-stream continue-stream] (j/branch stream [pred (constantly true])]
(j/to divert-stream topic)
continue-stream)
this abstraction, IMO, would feel really good in the library proper because it provides a useful layer on top of j/branch
to handle what i'd think is a common use-case (again, failure topics, etc) 4
@ddouglass I don't think we are against abstractions that are not light wrappers around the java API, so that function could be useful, feel free to open a pr if you like
👌 i'll be working on it and get something up
PR is up 🙂