Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve FlowBuilderApi #152

Closed
bitzl opened this issue Apr 3, 2020 · 0 comments · Fixed by #166
Closed

Improve FlowBuilderApi #152

bitzl opened this issue Apr 3, 2020 · 0 comments · Fixed by #166
Labels
breaking Marks a breaking change
Milestone

Comments

@bitzl
Copy link
Member

bitzl commented Apr 3, 2020

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 → IndexRequest
FlowBuilder2.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 types
FlowBuilder2.flow(
    new Type<SomeMessage>(){},
    new Type<Map<String, Item>>(){},
    new Type<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
@bitzl bitzl added the breaking Marks a breaking change label Apr 3, 2020
@bitzl bitzl added this to the Flusswerk 4.0 milestone Apr 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Marks a breaking change
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant