onyx

FYI: alternative Onyx :onyx: chat is at <https://gitter.im/onyx-platform/onyx> ; log can be found at <https://clojurians-log.clojureverse.org/onyx/index.html>
devn 2018-01-29T18:36:52.000438Z

n00b question: is it ill-advised to use onyx synchronous request/response-type workflows?

michaeldrogalis 2018-01-29T18:41:31.000154Z

@devn You can get away with it to a limited capacity if the round-trip time isn't huge with things like batch/bulk functions, but in general you're better off designing for asynchrony.

devn 2018-01-29T18:45:41.000402Z

@michaeldrogalis

devn 2018-01-29T18:46:00.000680Z

err @michaeldrogalis define limited capacity 🙂

michaeldrogalis 2018-01-29T18:49:07.000518Z

I wouldn't block progress for more than a few seconds. I misquoted - by the way. Batch functions are for async. tasks that need to be done fully synchronously.

devn 2018-01-29T18:49:10.000566Z

Other n00b questions include: - If I have a set of parallel steps, can I do something like switch to a fail branch if they don't all succeed?

michaeldrogalis 2018-01-29T18:49:19.000653Z

You can still do it that way, but I wanted to correct it for the record

michaeldrogalis 2018-01-29T18:49:55.000472Z

Flow conditions are the closest thing to help you there, but that sounds like more in the territory of a workflow engine.

devn 2018-01-29T18:50:09.000266Z

that's exactly what it is 🙂

devn 2018-01-29T18:50:30.000249Z

really trying not to reinvent the wheel and looking at all of the options we have

michaeldrogalis 2018-01-29T18:50:32.000221Z

You can still do it in Onyx, but it would look a little differently. Onyx is a streaming engine.

michaeldrogalis 2018-01-29T18:50:54.000188Z

Can I get a bit wider description of the problem to make a suggestion? 🙂

devn 2018-01-29T18:51:24.000863Z

Yeah, sorry, should have started there. 🙂

devn 2018-01-29T18:59:40.000404Z

We have a legacy system written in Ruby that uses resque to manage job states. Most of our customer integrations are asynch, but one of them we're building out right now is synchronous. Some jobs in the workflow are retryable. Some jobs can happen in parallel (for instance, two separate jobs hit two different APIs to pull down relevant data and a future step merges the results). It would be nice if something in the clojure ecosystem existed where I could just specify some clojure functions, tag them as retriable, specify which functions can run in parallel, define failure branches, etc. Think: a subset of Amazon's states language, applied to Clojure functions. We've been looking at AWS step functions, but there are a number of things that don't seem particularly great about them, like the local testing and development story for starters.

devn 2018-01-29T19:01:04.000801Z

Basically, we need state machine with some bells and whistles. We want to keep our options open on deploying the tasks in one app, or as separate reusable tasks that are shared by multiple workflows.

devn 2018-01-29T19:01:41.000022Z

Is that clear as mud? 🙂

michaeldrogalis 2018-01-29T19:08:37.000146Z

Onyx is conceptually close to your description of "some clojure functions, tag them as retriable, specify which functions can run in parallel, define failure branches, etc", except everything is retryable to completion and all tasks in a job run in parallel.

michaeldrogalis 2018-01-29T19:09:03.000827Z

I think if you design it CQRS style, Onyx is a really good fit for what you're trying to do.