Fluxtion embeddable Java complex event processor

Thanks for the question. I do not know kotlin flow, it seems similar to RxJava. There are many differences, its a really good idea for an article. Some thoughts that strike me straighaway

Fluxtion is built to handle infinite streams, I cant tell are kotlin flows for processing batched data in a co-routine

Fluxtion is concerned with graph processing and handling multiple event types, is kotlin flow more focused on single pipeline?. A single Fluxtion processor has multiple paths that diverge and converge. The path is determined by the event type. Elements on the path are Fluxtion libraries or user functions. If you see https://github.com/v12technology/fluxtion-quickstart, input events are bytes(fluxtion generates a CSV parser) or SensorReading. The flow merges and applies grouping, windowing and filtering. The flow diverges and integrates a user function to perform an action.

There is no single output in a Fluxtion processor, any node can publish data or invoke user code, it operates like a network of conditional statements

Fluxtion actually serialises the graph as code, potentially ahead of time. Other event processing systems infer the behaviour at rumtime. If you are in a serverless environment where quick startup and short runs are cost effective this is very important. For the example above see - https://github.com/v12technology/fluxtion-quickstart/tree/ma.... The entry point is https://github.com/v12technology/fluxtion-quickstart/blob/ma...

When dealing with graphs it becomes very confusing to debug and fix problems, having code really does reduce the maintenance cost.

We are concerned with zero-cost abstraction, that is trying to use as few resources as possible when processing. We have an example here - http://fluxtion.com/solutions/high-performance-flight-analys.... This processes 30 million records a second with zero-gc, including soup-nuts processing

We support annotations for injecting dependencies. Each injected instance can inject dependencies etc. recursively. I think a kotlin flow requires the user to explicitly wire together all nodes. Fluxtion encourages re-use of graphs/sub-graphs. The Fluxtion compiler will then construct a processor that merges all the nodes and serialise a processor solution

Basically Fluxtion removes the need for the developer to solve all the complexities if some can be inferred. I have an article in progress about managing an FX portfolio where hedges are executed if the risk is too high in a currency. Its interesting as events handled are config, trades, control signals, Fx rates, there are stateful calculations and orders are pushed out. The execution graph is here https://raw.githubusercontent.com/gregv12/articles/master/20...

Fluxtion is not concerned with handling backpressure it handles events as fast as it can. The pipeline sending events to an event processor is expected to manage back pressure.

I hope this helps