Alternative way of defining Graph Stages

[jorkey]

Hi. Could anyone review my PR #121?

[jorkey]

It seems I got into still water..

[johanandren]

So much things to do and so little time to do it in I'm afraid, and reviews do take a lot of time, so I can't give you any estimate on when we'll get to review it, sorry!

My gut feeling is that it is quite intricate/complex machinery/API for something we don't hear much complaints about/see many problems with. I have only very quickly skimmed the PR though.

In general, for future contributions it may help to start out with a discussion of the problem as an issue first before making a more advanced PR like this.

[jorkey]

Thank you very much for your answer.

I'm writing a server on Akka Streams, which has several tens of thousands of lines of source code. All server components are exclusively components of the Graph Stage. Dozens of static components are materialized into a single complex graph. For creating/removing and interacting with temporary components, I used own Dynamic Flow.

Combining all the components into a single complex graph, I got all the benefits of Akka Streams. At the same time, there was a problem of convenient back-pressure monitoring. Using manual pull/grab/push control within each Graph Stage, it's hard to avoid mistakes, but it's easy to complicate the code. And if consider that the use of Akka Streams does not exclude a problem like deadlock, revealing the potential cause of such a situation in the absence of a descriptive part of the back-pressure control becomes very difficult task.

Therefore, there was an idea of creating a higher level GraphStageLogic, the use of which would allow:

• get rid of the use of low-level pull/grab/push
• сoncisely describe the back-pressure policy within Graph Stage
• define buffers of the outlets with arbitrary OverflowStrategy
• handle an element from the inlet when all the outlets to which writing can be made will be available
• handle the event from the timer when all the outlets into which the writing can be made will be available

All these tasks are solved by the LinkedLogics/TimerLinkedLogics components, which has been successfully applied in my system for more than a year.
I think that the use of my LinkedLogics/TimerLinkedLogics with DynamicFlow components will allow many developers to completely abandon the direct use of Actors and switch to full-featured use of Akka Streams.

I will be glad for the further discussion.