Hi Matthias, I use a few of the methods that you're pointing out that will be deprecated and don't have an apparent alternative, so I wanted to just let you know what they are and what my use-cases are for them.
First of all, I use a combination of DSL and PAPI in the same application very happily. It looks like this API would not permit that at all... it looks like the intent here is to block that kind of usage, but as the DSL is not extensible (short of building on "internal" API classes and using reflection), this creates some real limitations in the type of applications that can be built. TopologyBuilder.addInternalTopic -- as we've discussed before, I have some reusable join components that build multiple processors w/ internal repartition topics. We use addInternalTopic to create application-id prefixed repartition topics. This could be worked around fairly easily. TopologyBuilder.nodeGroups & TopologyBuilder.build -- I have an option in my KS app to run once & output a graphviz document with my entire topology for debugging and analysis purposes; I use these methods to create ProcessorTopology instances to inspect the topology and create this output. I don't really see any alternative approach with this new API. KStreamBuilder.newName -- Similar to addInternalTopic, I use this to create processor names in reusable components. Lacking this method would be fairly easy to work around. Mathieu On Fri, Feb 3, 2017 at 4:33 PM, Matthias J. Sax <matth...@confluent.io> wrote: > Hi All, > > I did prepare a KIP to do some cleanup some of Kafka's Streaming API. > > Please have a look here: > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 120%3A+Cleanup+Kafka+Streams+builder+API > > Looking forward to your feedback! > > > -Matthias > >
