You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The FlowBuilde api has quite a big surface in which developers can get a little lost. Therefore a simplified builder pattern is proposed:
Simple Construction FlowBuilder should have no public constructor, only a minimal set of useful static construction methods (parameters are classes or types):
// FlowBuilder for Flow with Transformer Document → IndexRequestFlowBuilder2.flow(IndexMessage.class, Document.class, IndexRequest.class);
// FlowBuilder for Flow with Transformer PublishingInfo → PublishingInfo (or no Transformer at all)FlowBuilder2.flow(PublishingMessage.class, PublishingInfo.class);
// Using Type class to support generic typesFlowBuilder2.flow(
newType<SomeMessage>(){},
newType<Map<String, Item>>(){},
newType<List<Document>>(){});
Drop supplier support for Reader/Transformer/Writer
As Reader, Transformer and Writer are supposed to be stateless (and threadsafe), on early requests a supplier functionality was added. Instead of a Reader, Transformer or Writer instance, a developer could register a supplier providing new instances for each processed message.
This is rarely used now and often a sign of deeper problems in the involved components. At the same time, it doubles the amount of API methods and adds weird type errors. Therefore, suppliers should be dropped. In the rare cases such a behavior is needed, developers can implement a sufficient replacement in the respective Reader, Transformer or Writer.
Offer seperate APIs for ETL and Single Step Flows
If #151 (Support one-step-processing) is implemented, a one-step-flow should not offer to register a Reader,Transformer or Writer.
Stateful Builder API
In theory there can be a statemachine for creating
stateDiagram
New: New Flow
note right of New
.read(Function<R, T> reader)
end note
Reader: Flow with Reader
note right of Reader
.transform(Function<T, W> transformer)
.write(Consumer<W> writer)
.write(Function<W, Message> writer)
.write(Function<W, List<Message>> writer)
end note
Transformer: Flow with Reader and Transformer
note left of Transformer
.write(Consumer<W> writer)
.write(Function<W, Message> writer)
.write(Function<W, List<Message>> writer)
end note
Complete: Flow Complete
note right of Complete
.write(Consumer<W> writer)Complete
.write(Function<W, Message> writer)
.write(Function<W, List<Message>> writer)
end note
Monitoring: Has Monitoring
note right of Monitoring
.cleanup()
.build()
end note
Cleanup: Has Cleanup Task
note left of Cleanup
.monitoring(Consumer<FlowStatus> monitoring)
.build()
end note
[*] --> New: FlowBuilder.flow()
New --> Reader: read()
Reader --> Transformer: transform()
Reader --> Complete: write()
Transformer --> Complete: write()
Complete --> Monitoring: monitoring()
Complete --> Cleanup: cleanup()
Monitoring --> Cleanup: cleanup()
Cleanup --> Monitoring: monitoring()
Cleanup --> [*]: build()
Monitoring --> [*]: build()
Loading
The text was updated successfully, but these errors were encountered:
The FlowBuilde api has quite a big surface in which developers can get a little lost. Therefore a simplified builder pattern is proposed:
Simple Construction
FlowBuilder
should have no public constructor, only a minimal set of useful static construction methods (parameters are classes or types):Drop supplier support for Reader/Transformer/Writer
As
Reader
,Transformer
andWriter
are supposed to be stateless (and threadsafe), on early requests a supplier functionality was added. Instead of aReader
,Transformer
orWriter
instance, a developer could register a supplier providing new instances for each processed message.This is rarely used now and often a sign of deeper problems in the involved components. At the same time, it doubles the amount of API methods and adds weird type errors. Therefore, suppliers should be dropped. In the rare cases such a behavior is needed, developers can implement a sufficient replacement in the respective
Reader
,Transformer
orWriter
.Offer seperate APIs for ETL and Single Step Flows
If #151 (Support one-step-processing) is implemented, a one-step-flow should not offer to register a
Reader
,Transformer
orWriter
.Stateful Builder API
In theory there can be a statemachine for creating
The text was updated successfully, but these errors were encountered: