This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (43)
- # boot (44)
- # chestnut (17)
- # cider (78)
- # cljs-dev (24)
- # cljsrn (16)
- # clojure (84)
- # clojure-dusseldorf (1)
- # clojure-italy (21)
- # clojure-losangeles (2)
- # clojure-russia (140)
- # clojure-sg (2)
- # clojure-spec (8)
- # clojure-uk (16)
- # clojurescript (23)
- # cursive (7)
- # datascript (1)
- # datomic (18)
- # docker (20)
- # ethereum (1)
- # fulcro (16)
- # garden (4)
- # graphql (27)
- # hoplon (9)
- # jobs (4)
- # luminus (34)
- # off-topic (6)
- # om (4)
- # onyx (35)
- # pedestal (3)
- # re-frame (24)
- # ring-swagger (15)
- # rum (6)
- # shadow-cljs (22)
- # spacemacs (8)
- # specter (22)
- # yada (7)
hi all, we're experimenting with onyx and loving it so far. one of our tasks needs to call an external rest api. how should we best handle the blocking call? should we park the thread or something else?
any help would be much appreciated
@ben.mumford Take a look at
@ben.mumford you can batch multiple requests concurrently and block inside the function
so i batch multiple requests, for each one send of the call to the external API and block?
so no parking and no go blocks required?
i think i see, the libraries referenced in the batch fn documentation make sense. make all the calls, resolve all the promises and return the list
exactly — so that way onyx treats the batch as a single blocking operation, and inside the batch you can still do things efficiently and asynchronous
with regards batch fn what do you do if one of the api calls fails?
you have to return a list the same length
my personal flavour to handle this is to just crash the task (i.e. throw an exception) and let onyx deal with it on a higher level
what happens to the messages then?
i need to read more on exceptions thrown from tasks
thanks for your help
are flow conditions like middleware then? i thought that was lifecycles?
a little bit yes — it’s more that it allows your messages/data to “flow” through your workflow based on predefined conditions
e.g. lifecycles allow me to “inject” certain information into a task when it launches (e.g. start a webserver)
flow conditions allow me to define how a message goes through my workflow dynamically — e.g., i can filter all messages that do not match a certain criteria
no doubt more stupid questions coming soon
What would be the high level sketch of how to make onyx part of a reactive web application? From the users perspective the webpage would just update automatically.
input -> ?? -> user not
input -> ??? <- user request
The clients could either subscribe to onyx directly in some form or maybe to a kafka topic.
You would output to a topic which routes the outputs to the correct client
You would include an id in the message which would correlate to a user’s web socket, and then your topic consumer would push the messages to the right web socket
Right. That makes sense, the area i’m less clear about is web sockets. But now I can focus on that area. thanks @lucasbradstreet