Akka streams materialization type

[Robert Wilton]

Hi,

I've been keeping an eye on the development of akka streams, and I was just taking a second look at it now.

There is one thing that I can't seem to get my head around, which is the explicit types associated with materialization.

Compared to the earlier beta versions, it feels to me that the adding explicit materialization types seems to have added quite a lot of complexity in the APIs for building and using flows and I can't see where they are particularly beneficial in the general case.

Presumably there was a compelling argument for adding them - I just can't figure out what it is! ;-)

Thanks,

Rob

[Endre Varga]

Hi Robert,

On Tue, Oct 6, 2015 at 3:29 PM, Robert Wilton <rgwi...@gmail.com> wrote:

Hi,

I've been keeping an eye on the development of akka streams, and I was just taking a second look at it now.

There is one thing that I can't seem to get my head around, which is the explicit types associated with materialization.

Compared to the earlier beta versions, it feels to me that the adding explicit materialization types seems to have added quite a lot of complexity in the APIs for building and using flows and I can't see where they are particularly beneficial in the general case.

They also removed quite a bit of complexity though:

 - more complex modules that needed to expose a materialized value needed to also expose the internal Sources/Sinks to the outside world, since those were keys to the MaterializedMap. Removal of this problem alone simplified the TCP interfaces greatly.

 - Only Sinks and Sources could have a materialized value before. This is no longer the case, and this is used already.

 - due to the MaterializedMap actually being, well, a Map, you cannot reuse the same Source/Sink twice in the same graph otherwise one would overwrite the others value in a non-deterministic (hash code dependent) manner

 - due to atomic (non-composite) Sink/Source being the keys to that map, it was not possible to use a transformed version of them and still access the value.

The added type-safety is just a nice bonus on top of these.

 

Presumably there was a compelling argument for adding them - I just can't figure out what it is! ;-)

If I need to summarize the above, incomplete list, then the short answer is: composability. The previous map-based model breaked down for anything non-trivial, while the current one, complex or not, actually works ;)

-Endre

 

Thanks,

Rob

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Robert Wilton]

Hi Endre,

Thanks for the explanation.

I was struggling to see why it was necessary for the flow to effectively generate an object as a side-effect of the materialization. 

I guess that this is a corollary of choosing a design where the elements of the flow are created indirectly (and hence you don't have direct access to the underlying objects that have been created).

Thanks again,
Rob

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/jtIq7GSEIaE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Endre Varga]

On Wed, Oct 7, 2015 at 4:26 PM, Robert Wilton <robert...@wilton.org.uk> wrote:

Hi Endre,

Thanks for the explanation.

I was struggling to see why it was necessary for the flow to effectively generate an object as a side-effect of the materialization. 

I guess that this is a corollary of choosing a design where the elements of the flow are created indirectly (and hence you don't have direct access to the underlying objects that have been created).

Yes, basically everything in Akka Streams is a "FactoryBuilder" since the DSLs build not the running thing but a factory for the running thing ;) This implies certain API design choices. 

-Endre