This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-01
Channels
- # 100-days-of-code (5)
- # adventofcode (234)
- # aleph (13)
- # announcements (2)
- # architecture (3)
- # bangalore-clj (1)
- # beginners (312)
- # calva (7)
- # cider (6)
- # cljdoc (3)
- # cljs-dev (30)
- # cljsrn (2)
- # clojure (40)
- # clojure-austin (2)
- # clojure-dev (65)
- # clojure-greece (1)
- # clojure-italy (29)
- # clojure-kc (1)
- # clojure-russia (2)
- # clojure-uk (26)
- # clojurebridge (1)
- # clojurescript (4)
- # cursive (11)
- # data-science (1)
- # datomic (43)
- # docker (1)
- # duct (7)
- # emacs (3)
- # figwheel-main (7)
- # fulcro (8)
- # garden (3)
- # graphql (8)
- # hyperfiddle (4)
- # off-topic (10)
- # other-languages (12)
- # pathom (4)
- # portkey (1)
- # remote-jobs (3)
- # rum (8)
- # shadow-cljs (40)
- # tools-deps (68)
- # unrepl (2)
- # vim (5)
I'm playing around with a module which has a key which resolves to a function which is not semantically a handler. Should I derive from :duct/handler anyhow?
:duct/handler
or :duct/module
?
The module is an attempt at modeling a microservice queue processor, so it needs a source function and a sink function. The source is a queue reader and the sink is a handler
In which case, you probably shouldn't derive from :duct/handler
. You don't need to - it's just semantic information - and :duct/handler
refers specifically to Ring handlers/
I was hoping that would be your opinion. The semantics were bugging me. Are "source" and "sink" at the right level of abstraction?
It seems a reasonable design to me.
Thanks. I'm still trying to work throuogh the model implications.