[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Jim Hazen]

With these latest foundational changes, is akka-http 2.0 intended to be the 
'spray parity' release?  If not, is there a roadmap for an akka-http client 
as rich as Spray's and akka-http server as performant as Spray's?

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Tim Harper]

Excellent work!!!

On Friday, November 6, 2015 at 6:19:49 AM UTC-7, Martynas Mickevičius wrote:
>
> *Dear Hakkers*
>
> we—the Akka committers—are very pleased to announce Akka Streams & HTTP 
> 2.0-M1, the first milestone of the upcoming 2.0 release. The overarching 
> theme of this milestone is unification, both in internals and API. Thanks 
> go to all of you who tried out Streams & HTTP 1.0, your feedback—both 
> direct and indirect—has been instrumental in making this library more 
> accessible and intuitive to use.
>
> There have been several changes in user facing APIs mostly driven by two 
> goals. First, reducing the number of overloaded methods helps IDEs and 
> compilers for both Scala and Java (especially Java 8), leads to more 
> meaningful error messages, and also makes discovery of methods easier via 
> API documentation or code completion. Second, we reduced the different ways 
> certain tasks can be achieved by reducing the number of helper methods, 
> taking away potentially confusing choices. While this means that in certain 
> cases the amount of boilerplate has grown slightly, the APIs reflect more 
> directly the underlying uniform model and hence feel more consistent than 
> before. Some highlights of these changes are (for the full list see the 
> migration guide for Java 
> 
>  and Scala 
> 
> ):
>
>- Methods for creating Flows, Sources etc. from Graphs are now called 
>fromGraph instead of wrap.
>- The number of FlowGraph builder methods has been reduced to the 
>necessary minimum.
>- In the Scala DSL the only graph building API is the arrow ~> 
>notation, the edge-based alternative (more klunky) API has been removed.
>- Creating Flows, Sources, etc. from Graphs now can be only done in 
>two steps, first creating the Graph, then using fromGraph to turn it into 
>the desired target type. The second step is only necessary when 
>subsequently using the combinators defined on the Source/Flow types, reuse 
>of processing setups is better done using the language-agnostic Graph type.
>
> *For the full list of changes see the Github milestone 
>  and 
> http-2.0-M1 
> *
>
> On the internals front the most important change is that we removed almost 
> all of the custom actor-based stage implementations, thanks to a new 
> abstraction called *GraphStage*. GraphStage is a new user API that 
> replaces FlexiMerge, FlexiRoute and AsyncStage. Compared to the previous 
> abstractions GraphStage is capable of modeling a stage with any number of 
> input and output ports and asynchronous notifications and without the 
> limitations that the FlexiMerge/FlexiRoute implementations suffered. A 
> testament to the flexibility and usefulness of this new stage design is 
> that nearly all of the built-in stages are now GraphStage based 
> implementations (with the remaining ones being scheduled to be 
> rewritten—there is no reason why dedicated actors are still needed given 
> the expressive power of GraphStage). A fun fact is that this rewrite also 
> resulted in 29% jar size reduction compared to the 1.0 artifact while 
> having more features than ever before.
>
> The new GraphStage already enabled us to unify and simplify a large amount 
> of internal code, it also provides a richer customization API for users for 
> building new stages, but this is just the beginning! This new abstraction 
> is the first step towards a very important goal we have, which is called 
> *fusing*. This feature will allow declarative demarcation of actor 
> boundaries backing a streaming graph, i.e. it will be now possible to 
> execute multiple stream processing steps inside one actor, reducing the 
> number of thread-hops where they are not necessary. This is also the 
> feature that will increase performance for various use cases, including 
> HTTP.
>
> On the Akka HTTP front much has happened as well. The documentation is now 
> mostly complete and several API, marshalling as well as configuration 
> improvements have been merged as well.
>
> We hope that this evolution of Akka Streams & HTTP goes into the right 
> direction, enabling Java and Scala developers to pick up this library as a 
> tool that is universally useful in their day to day coding. To this end we 
> continue to depend on all your excellent and honest feedback, so please try 
> it out!
>
> We would like to give our special thanks and kudos to Alexander Golubev, 
> who has been contributing a steady stream of high quality, and often 
> non-trivial pull requests to Akka Streams. Thanks!
>
> Similarly, we would like to give a huge thanks and kudos to @2beaucoup, a 
> 

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Gary Struthers]

>
> The 2.0M-1 docs have a TODO for GraphStage. In the meantime is there 
> anything out there to help start using them?
>

Gary 

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Konrad Malawski]

Hi Gary,
yes, you should read the AsyncStage => GraphStage migration:
http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0-M1/scala/migration-guide-1.0-2.x-scala.html#asyncstage-has-been-replaced-by-graphstage

It's a the most complex translation I think, so once you grasp that one you 
should be able to figure out how to translate your Flexi things.

There will be an M2 soon, then we'll explain in detail how to migrate from 
Flexi things.

Hope this helps!

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Typesafe

On 7 November 2015 at 01:23:17, Konrad Malawski (konrad.malaw...@typesafe.com) 
wrote:

Very glad the upgrade was so smooth for you Mathias!
We know it's a bit of mechanical changes in some spots, but should be farily 
simple (and outlined in the migration guide).

Happy hakking!

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Typesafe

On 6 November 2015 at 22:34:26, Mathias Bogaert (mathias.boga...@gmail.com) 
wrote:

Great! Had to make only one change to my Akka HTTP API: replace 
akka.http.scaladsl.server.directives.UserCredentials with 
akka.http.scaladsl.server.directives.Credentials.

On Friday, 6 November 2015 13:19:49 UTC, Martynas Mickevičius wrote:
Dear Hakkers

we—the Akka committers—are very pleased to announce Akka Streams & HTTP 2.0-M1, 
the first milestone of the upcoming 2.0 release. The overarching theme of this 
milestone is unification, both in internals and API. Thanks go to all of you 
who tried out Streams & HTTP 1.0, your feedback—both direct and indirect—has 
been instrumental in making this library more accessible and intuitive to use.

There have been several changes in user facing APIs mostly driven by two goals. 
First, reducing the number of overloaded methods helps IDEs and compilers for 
both Scala and Java (especially Java 8), leads to more meaningful error 
messages, and also makes discovery of methods easier via API documentation or 
code completion. Second, we reduced the different ways certain tasks can be 
achieved by reducing the number of helper methods, taking away potentially 
confusing choices. While this means that in certain cases the amount of 
boilerplate has grown slightly, the APIs reflect more directly the underlying 
uniform model and hence feel more consistent than before. Some highlights of 
these changes are (for the full list see the migration guide for Java and 
Scala):

Methods for creating Flows, Sources etc. from Graphs are now called fromGraph 
instead of wrap.
The number of FlowGraph builder methods has been reduced to the necessary 
minimum.
In the Scala DSL the only graph building API is the arrow ~> notation, the 
edge-based alternative (more klunky) API has been removed.
Creating Flows, Sources, etc. from Graphs now can be only done in two steps, 
first creating the Graph, then using fromGraph to turn it into the desired 
target type. The second step is only necessary when subsequently using the 
combinators defined on the Source/Flow types, reuse of processing setups is 
better done using the language-agnostic Graph type.
For the full list of changes see the Github milestone and http-2.0-M1

On the internals front the most important change is that we removed almost all 
of the custom actor-based stage implementations, thanks to a new abstraction 
called GraphStage. GraphStage is a new user API that replaces FlexiMerge, 
FlexiRoute and AsyncStage. Compared to the previous abstractions GraphStage is 
capable of modeling a stage with any number of input and output ports and 
asynchronous notifications and without the limitations that the 
FlexiMerge/FlexiRoute implementations suffered. A testament to the flexibility 
and usefulness of this new stage design is that nearly all of the built-in 
stages are now GraphStage based implementations (with the remaining ones being 
scheduled to be rewritten—there is no reason why dedicated actors are still 
needed given the expressive power of GraphStage). A fun fact is that this 
rewrite also resulted in 29% jar size reduction compared to the 1.0 artifact 
while having more features than ever before.

The new GraphStage already enabled us to unify and simplify a large amount of 
internal code, it also provides a richer customization API for users for 
building new stages, but this is just the beginning! This new abstraction is 
the first step towards a very important goal we have, which is called fusing. 
This feature will allow declarative demarcation of actor boundaries backing a 
streaming graph, i.e. it will be now possible to execute multiple stream 
processing steps inside one actor, reducing the number of thread-hops where 
they are not necessary. This is also the feature that will increase performance 
for various use cases, including HTTP.

On the Akka HTTP front much has happened as well. The documentation is now 
mostly complete and several API, marshalling as well as configuration 
improvements have been merged as well.

We hope that this evolution of Akka Streams & HTTP goes into 

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Andrew Gaydenko]

Konrad, hi!

Thanks for the explanation, now i see the M1 is more interesting (for me) 
than it can be visible at first :) I remember the Play team intention to 
(officially, not experimental) switch to Akka Stream from Iteratees only 
when performance will be comparable. So, that future is moving to reality, 
great!

On Saturday, November 7, 2015 at 8:15:55 PM UTC+3, Konrad Malawski wrote:
>
> Hi Andrew,
> it is the most important step – fusing is *the* feature to enable high 
> throughput + single materialization (per request) for Akka HTTP.
> The feature in 2.0-M1 allows to to apply the fusing on fan-out and fan-in 
> operations (we could do it previously for linear stages),
> so it is a major step towards the promised performance improvements.
>
> Actually enabling fusing on parts of the HTTP pipeline will be the next 
> step, which will then make a noticeable impact on perf.
>
> Hope this explains things!
>
> -- Konrad
>
>

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Konrad Malawski]

>
> On Friday, November 6, 2015 at 4:19:49 PM UTC+3, Martynas Mickevičius 
> wrote:
>>
>> ... This is also the feature that will increase performance for various 
>> use cases, including HTTP.
>>
>
> Is it just the first step, or significant part of the way, or almost the 
> whole way to make Akka HTTP comparable with Play/Iteratee HTTP 
> implementation in terms of performance?
>

Hi Andrew,
it is the most important step – fusing is *the* feature to enable high 
throughput + single materialization (per request) for Akka HTTP.
The feature in 2.0-M1 allows to to apply the fusing on fan-out and fan-in 
operations (we could do it previously for linear stages),
so it is a major step towards the promised performance improvements.

Actually enabling fusing on parts of the HTTP pipeline will be the next 
step, which will then make a noticeable impact on perf.

Hope this explains things!

-- Konrad

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Konrad Malawski]

Very glad the upgrade was so smooth for you Mathias!
We know it's a bit of mechanical changes in some spots, but should be farily 
simple (and outlined in the migration guide).

Happy hakking!

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Typesafe

On 6 November 2015 at 22:34:26, Mathias Bogaert (mathias.boga...@gmail.com) 
wrote:

Great! Had to make only one change to my Akka HTTP API: replace 
akka.http.scaladsl.server.directives.UserCredentials with 
akka.http.scaladsl.server.directives.Credentials.

On Friday, 6 November 2015 13:19:49 UTC, Martynas Mickevičius wrote:
Dear Hakkers

we—the Akka committers—are very pleased to announce Akka Streams & HTTP 2.0-M1, 
the first milestone of the upcoming 2.0 release. The overarching theme of this 
milestone is unification, both in internals and API. Thanks go to all of you 
who tried out Streams & HTTP 1.0, your feedback—both direct and indirect—has 
been instrumental in making this library more accessible and intuitive to use.

There have been several changes in user facing APIs mostly driven by two goals. 
First, reducing the number of overloaded methods helps IDEs and compilers for 
both Scala and Java (especially Java 8), leads to more meaningful error 
messages, and also makes discovery of methods easier via API documentation or 
code completion. Second, we reduced the different ways certain tasks can be 
achieved by reducing the number of helper methods, taking away potentially 
confusing choices. While this means that in certain cases the amount of 
boilerplate has grown slightly, the APIs reflect more directly the underlying 
uniform model and hence feel more consistent than before. Some highlights of 
these changes are (for the full list see the migration guide for Java and 
Scala):

Methods for creating Flows, Sources etc. from Graphs are now called fromGraph 
instead of wrap.
The number of FlowGraph builder methods has been reduced to the necessary 
minimum.
In the Scala DSL the only graph building API is the arrow ~> notation, the 
edge-based alternative (more klunky) API has been removed.
Creating Flows, Sources, etc. from Graphs now can be only done in two steps, 
first creating the Graph, then using fromGraph to turn it into the desired 
target type. The second step is only necessary when subsequently using the 
combinators defined on the Source/Flow types, reuse of processing setups is 
better done using the language-agnostic Graph type.
For the full list of changes see the Github milestone and http-2.0-M1

On the internals front the most important change is that we removed almost all 
of the custom actor-based stage implementations, thanks to a new abstraction 
called GraphStage. GraphStage is a new user API that replaces FlexiMerge, 
FlexiRoute and AsyncStage. Compared to the previous abstractions GraphStage is 
capable of modeling a stage with any number of input and output ports and 
asynchronous notifications and without the limitations that the 
FlexiMerge/FlexiRoute implementations suffered. A testament to the flexibility 
and usefulness of this new stage design is that nearly all of the built-in 
stages are now GraphStage based implementations (with the remaining ones being 
scheduled to be rewritten—there is no reason why dedicated actors are still 
needed given the expressive power of GraphStage). A fun fact is that this 
rewrite also resulted in 29% jar size reduction compared to the 1.0 artifact 
while having more features than ever before.

The new GraphStage already enabled us to unify and simplify a large amount of 
internal code, it also provides a richer customization API for users for 
building new stages, but this is just the beginning! This new abstraction is 
the first step towards a very important goal we have, which is called fusing. 
This feature will allow declarative demarcation of actor boundaries backing a 
streaming graph, i.e. it will be now possible to execute multiple stream 
processing steps inside one actor, reducing the number of thread-hops where 
they are not necessary. This is also the feature that will increase performance 
for various use cases, including HTTP.

On the Akka HTTP front much has happened as well. The documentation is now 
mostly complete and several API, marshalling as well as configuration 
improvements have been merged as well.

We hope that this evolution of Akka Streams & HTTP goes into the right 
direction, enabling Java and Scala developers to pick up this library as a tool 
that is universally useful in their day to day coding. To this end we continue 
to depend on all your excellent and honest feedback, so please try it out!

We would like to give our special thanks and kudos to Alexander Golubev, who 
has been contributing a steady stream of high quality, and often non-trivial 
pull requests to Akka Streams. Thanks!

Similarly, we would like to give a huge thanks and kudos to @2beaucoup, a 
long-time Spray contributor, who has been helping Akka HTTP succeed with his 
excellent 

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Gabriel Volpe]

Excellent news!!! 

Thanks for the hard work, I'm gonna give it a try!

El viernes, 6 de noviembre de 2015, 13:19:49 (UTC), Martynas Mickevičius 
escribió:
>
> *Dear Hakkers*
>
> we—the Akka committers—are very pleased to announce Akka Streams & HTTP 
> 2.0-M1, the first milestone of the upcoming 2.0 release. The overarching 
> theme of this milestone is unification, both in internals and API. Thanks 
> go to all of you who tried out Streams & HTTP 1.0, your feedback—both 
> direct and indirect—has been instrumental in making this library more 
> accessible and intuitive to use.
>
> There have been several changes in user facing APIs mostly driven by two 
> goals. First, reducing the number of overloaded methods helps IDEs and 
> compilers for both Scala and Java (especially Java 8), leads to more 
> meaningful error messages, and also makes discovery of methods easier via 
> API documentation or code completion. Second, we reduced the different ways 
> certain tasks can be achieved by reducing the number of helper methods, 
> taking away potentially confusing choices. While this means that in certain 
> cases the amount of boilerplate has grown slightly, the APIs reflect more 
> directly the underlying uniform model and hence feel more consistent than 
> before. Some highlights of these changes are (for the full list see the 
> migration guide for Java 
> 
>  and Scala 
> 
> ):
>
>- Methods for creating Flows, Sources etc. from Graphs are now called 
>fromGraph instead of wrap.
>- The number of FlowGraph builder methods has been reduced to the 
>necessary minimum.
>- In the Scala DSL the only graph building API is the arrow ~> 
>notation, the edge-based alternative (more klunky) API has been removed.
>- Creating Flows, Sources, etc. from Graphs now can be only done in 
>two steps, first creating the Graph, then using fromGraph to turn it into 
>the desired target type. The second step is only necessary when 
>subsequently using the combinators defined on the Source/Flow types, reuse 
>of processing setups is better done using the language-agnostic Graph type.
>
> *For the full list of changes see the Github milestone 
>  and 
> http-2.0-M1 
> *
>
> On the internals front the most important change is that we removed almost 
> all of the custom actor-based stage implementations, thanks to a new 
> abstraction called *GraphStage*. GraphStage is a new user API that 
> replaces FlexiMerge, FlexiRoute and AsyncStage. Compared to the previous 
> abstractions GraphStage is capable of modeling a stage with any number of 
> input and output ports and asynchronous notifications and without the 
> limitations that the FlexiMerge/FlexiRoute implementations suffered. A 
> testament to the flexibility and usefulness of this new stage design is 
> that nearly all of the built-in stages are now GraphStage based 
> implementations (with the remaining ones being scheduled to be 
> rewritten—there is no reason why dedicated actors are still needed given 
> the expressive power of GraphStage). A fun fact is that this rewrite also 
> resulted in 29% jar size reduction compared to the 1.0 artifact while 
> having more features than ever before.
>
> The new GraphStage already enabled us to unify and simplify a large amount 
> of internal code, it also provides a richer customization API for users for 
> building new stages, but this is just the beginning! This new abstraction 
> is the first step towards a very important goal we have, which is called 
> *fusing*. This feature will allow declarative demarcation of actor 
> boundaries backing a streaming graph, i.e. it will be now possible to 
> execute multiple stream processing steps inside one actor, reducing the 
> number of thread-hops where they are not necessary. This is also the 
> feature that will increase performance for various use cases, including 
> HTTP.
>
> On the Akka HTTP front much has happened as well. The documentation is now 
> mostly complete and several API, marshalling as well as configuration 
> improvements have been merged as well.
>
> We hope that this evolution of Akka Streams & HTTP goes into the right 
> direction, enabling Java and Scala developers to pick up this library as a 
> tool that is universally useful in their day to day coding. To this end we 
> continue to depend on all your excellent and honest feedback, so please try 
> it out!
>
> We would like to give our special thanks and kudos to Alexander Golubev, 
> who has been contributing a steady stream of high quality, and often 
> non-trivial pull requests to Akka Streams. Thanks!
>
> Similarly, we would like 

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Andrew Gaydenko]

Great!

On Friday, November 6, 2015 at 4:19:49 PM UTC+3, Martynas Mickevičius wrote:
>
> ... This is also the feature that will increase performance for various 
> use cases, including HTTP.
>

Is it just the first step, or significant part of the way, or almost the 
whole way to make Akka HTTP comparable with Play/Iteratee HTTP 
implementation in terms of performance?

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka Stream and Http 2.0-M1 Released!

[Mathias Bogaert]

Great! Had to make only one change to my Akka HTTP API: 
replace akka.http.scaladsl.server.directives.UserCredentials 
with akka.http.scaladsl.server.directives.Credentials.

On Friday, 6 November 2015 13:19:49 UTC, Martynas Mickevičius wrote:
>
> *Dear Hakkers*
>
> we—the Akka committers—are very pleased to announce Akka Streams & HTTP 
> 2.0-M1, the first milestone of the upcoming 2.0 release. The overarching 
> theme of this milestone is unification, both in internals and API. Thanks 
> go to all of you who tried out Streams & HTTP 1.0, your feedback—both 
> direct and indirect—has been instrumental in making this library more 
> accessible and intuitive to use.
>
> There have been several changes in user facing APIs mostly driven by two 
> goals. First, reducing the number of overloaded methods helps IDEs and 
> compilers for both Scala and Java (especially Java 8), leads to more 
> meaningful error messages, and also makes discovery of methods easier via 
> API documentation or code completion. Second, we reduced the different ways 
> certain tasks can be achieved by reducing the number of helper methods, 
> taking away potentially confusing choices. While this means that in certain 
> cases the amount of boilerplate has grown slightly, the APIs reflect more 
> directly the underlying uniform model and hence feel more consistent than 
> before. Some highlights of these changes are (for the full list see the 
> migration guide for Java 
> 
>  and Scala 
> 
> ):
>
>- Methods for creating Flows, Sources etc. from Graphs are now called 
>fromGraph instead of wrap.
>- The number of FlowGraph builder methods has been reduced to the 
>necessary minimum.
>- In the Scala DSL the only graph building API is the arrow ~> 
>notation, the edge-based alternative (more klunky) API has been removed.
>- Creating Flows, Sources, etc. from Graphs now can be only done in 
>two steps, first creating the Graph, then using fromGraph to turn it into 
>the desired target type. The second step is only necessary when 
>subsequently using the combinators defined on the Source/Flow types, reuse 
>of processing setups is better done using the language-agnostic Graph type.
>
> *For the full list of changes see the Github milestone 
>  and 
> http-2.0-M1 
> *
>
> On the internals front the most important change is that we removed almost 
> all of the custom actor-based stage implementations, thanks to a new 
> abstraction called *GraphStage*. GraphStage is a new user API that 
> replaces FlexiMerge, FlexiRoute and AsyncStage. Compared to the previous 
> abstractions GraphStage is capable of modeling a stage with any number of 
> input and output ports and asynchronous notifications and without the 
> limitations that the FlexiMerge/FlexiRoute implementations suffered. A 
> testament to the flexibility and usefulness of this new stage design is 
> that nearly all of the built-in stages are now GraphStage based 
> implementations (with the remaining ones being scheduled to be 
> rewritten—there is no reason why dedicated actors are still needed given 
> the expressive power of GraphStage). A fun fact is that this rewrite also 
> resulted in 29% jar size reduction compared to the 1.0 artifact while 
> having more features than ever before.
>
> The new GraphStage already enabled us to unify and simplify a large amount 
> of internal code, it also provides a richer customization API for users for 
> building new stages, but this is just the beginning! This new abstraction 
> is the first step towards a very important goal we have, which is called 
> *fusing*. This feature will allow declarative demarcation of actor 
> boundaries backing a streaming graph, i.e. it will be now possible to 
> execute multiple stream processing steps inside one actor, reducing the 
> number of thread-hops where they are not necessary. This is also the 
> feature that will increase performance for various use cases, including 
> HTTP.
>
> On the Akka HTTP front much has happened as well. The documentation is now 
> mostly complete and several API, marshalling as well as configuration 
> improvements have been merged as well.
>
> We hope that this evolution of Akka Streams & HTTP goes into the right 
> direction, enabling Java and Scala developers to pick up this library as a 
> tool that is universally useful in their day to day coding. To this end we 
> continue to depend on all your excellent and honest feedback, so please try 
> it out!
>
> We would like to give our special thanks and kudos to Alexander Golubev, 
> who has been contributing a steady stream of high quality, and