[
https://issues.apache.org/jira/browse/APEXMALHAR-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15311443#comment-15311443
]
Siyuan Hua commented on APEXMALHAR-2099:
----------------------------------------
[~ilganeli] When we started working on high level API, we asked the question.
We already have Operator API which supports a much greater variety of
transformations, why do we need high-level API which would definitely sacrifice
some sort of flexibility. Beam API is kind of in the middle of low level API
like our Operator API and some high level API like Flink/Spark. A main reason
is we want to make another API that is easy to start with and also easy to use
in most cases. Flink, Spark and even JDK 8 pick same flavour for some reason.
Think about some developer who's new to parallel stream processing. How can
they find out which existing transformation library fit into their needs? By
search for all sub classes of PTransform and use apply, apply, apply to chain
them together or look at the first-order self-descriptive methods(map, filter,
flatmap...) in one class? If I'm a beginner I definitely prefer the facade
pattern.
I'm not saying Beam API is ugly, if they can have only one API. They have no
choice but the full flexibility to support Google Data Flow Model.
> Identify overlap between Beam API and existing Apex Stream API
> --------------------------------------------------------------
>
> Key: APEXMALHAR-2099
> URL: https://issues.apache.org/jira/browse/APEXMALHAR-2099
> Project: Apache Apex Malhar
> Issue Type: Sub-task
> Reporter: Ilya Ganelin
>
> There should be some overlap between the Beam API and the recently released
> Apex Stream API. This task captures the need to understand and document this
> overlap.
> AC:
> * A document or JIRA comment identifying which components of the Beam API are
> implement, similar, or absent within the Apex Stream API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
