Local Development and Testing

Application Development

The USP of flux is that it does not intrude traditional application development. Apart from using a few Flux-specific annotations and a few gotchas, your Java code remains largely the same.

Even when using Flux, things like Unit Tests/Integration Tests or local runs for an application need not change and neither would they require any additional software running on the developer's box.

Modelling Flows

Flux has a simple way to infer "dependencies" between tasks. Dependencies govern flow of task executions.

Consider the following code snippet

Data dataSet1 =  retrieveData(userId1);
Data dataSet2 =  retrieveData(userId2);
notify(dataSet1);
log(dataSet2);

In the above example, the 2 calls to retrieveData are independent of each other, i.e the Flux engine deems them fit for execution as soon as the workflow is invoked. Execution of notify and log depends on the output of retrieveData(userId1). Hence, the execution for these tasks can only be triggered once we have dataSet1 variable available as a result of execution of retrieveData

Notice how the above code can be unit tested and even run locally just like vanilla java code.

Gotchas

Reentrant methods and Stateless Classes

Storing state in classes is like maintaining a global variable across multiple method invocations. In case of Flux, a method (within a workflow or across workflows) can be invoked in any available JVM - so maintaining a variable in one class in one JVM is pointless and will result in bugs. There are plans to support a Global Variable like construct by storing data within Flux. However, this is not supported yet.

Backward Compatibility of methods

When deploying code, there will be a time period where different versions of the same method exist in the production cluster. Hence, it is important to maintain backward compatibility There is provision to manage versioned tasks and workflows using the version attribute of the respective annotations. This, however, is not supported in the current version. A simple (but inconvenient) workaround is to change the name of tasks that break backward compatibility.