-
Notifications
You must be signed in to change notification settings - Fork 43
Local Development and Testing
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.
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(dataSet1);
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.
Please refer to Examples page to get a better idea at modelling flows using Flux
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.
Don't use Underscore(_) in Workflow or Task method names as Underscore is used in Flux as a separator internally.
Varargs (variable arguments) are not supported in task parameters, but allowed in workflow parameters.