This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-26
Channels
- # babashka (7)
- # beginners (85)
- # calva (39)
- # cider (3)
- # clara (1)
- # clj-kondo (10)
- # clojure (194)
- # clojure-europe (36)
- # clojure-madison (2)
- # clojure-nl (13)
- # clojure-spec (11)
- # clojure-uk (2)
- # clojurescript (17)
- # community-development (5)
- # component (9)
- # conjure (4)
- # core-async (3)
- # cursive (32)
- # data-science (26)
- # datomic (31)
- # graalvm (22)
- # holy-lambda (31)
- # honeysql (7)
- # introduce-yourself (1)
- # jobs (9)
- # jobs-rus (1)
- # lsp (3)
- # malli (9)
- # off-topic (54)
- # pathom (27)
- # pedestal (6)
- # portal (1)
- # re-frame (4)
- # releases (1)
- # remote-jobs (1)
- # sci (3)
- # shadow-cljs (4)
- # spacemacs (13)
- # vim (14)
- # xtdb (3)
How frequently do you find yourself doing the my.namespace.api + my.namespace.api.async pattern when interacting with APIs? Is it step 1 for wrapping an api? I've found I almost always want (identical) async and non async interfaces and this pattern has been the nicest to use as a user of the wrapped api. But it does kinda lead to a lot of namespaces in apps that wrap a lot of things
I usually default to an async implementation which takes a callback, and a blocking arity which delivers a promise on that callback and returns derefs it. Callbacks can easily be adapted to different async libraries
the api clients I have written lately end up following a aws-api like pattern where the api is kind of a single function "invoke" that takes a map describing some operation to perform and returns the result, and I often have an invoke! which returns a channel, and invoke!! which calls invoke! and then calls >!!