Akka Streams & HTTP 1.0-RC1 Announcement

[Patrik Nordwall]

Dear Hakkers,

we—the Akka committers—are exceptionally proud to present the first RELEASE CANDIDATE or Akka Streams & HTTP. While this is not the end of the journey—several features are going to be added after 1.0—the time has come to declare a (very) useful subset of the intended functionality ready for public consumption. Since the last milestone we have added the following high-level features:

• a TestKit for streams

• proper naming for all parts of a flow topology (see .named)

• add SslTls stage including support for session renegotiation

• added ActorRefSink and ActorRefSource for simple Actor integration

• data flow logging by a prepackaged combinator (see .log)

• Source and Sink for files (using FileChannel) as well as for InputStream/OutputStream

• HTTP client with connection pooling and idempotent request retry

• … and (wait for it) … Websockets :-)

In addition we fixed many small things, as usual, and we also did some last renames and reorganizations in order to offer a consistent API:

• Java functional interfaces moved to akka-actor (2.3.10, see akka.japi.function)

• improved Java compilation error messages by adding arity to method name in flow factories

• made OperationAttributes language-independent and also extensible, dispatcher and supervision properties moved to ActorOperationAttributes

• removed .section in favor of .withAttributes and .via

• moved FlattenStrategy into the Java/Scala DSLs

• reorganized the project structure and package hierarchy of HTTP to offer consistent and equivalent Java & Scala APIs

• relaxed method signatures to accept Graphs instead of the more specific Source/Flow/Sink types to enable free reuse of blueprints between Java & Scala

• renamed StreamTcp to Tcp and the bind method takes interface and port parameters instead of InetSocketAddress

On the State of HTTPS

While we now have all the ingredients—SslTls and HTTP are BidiFlows that can be connected—we do not yet have nice convenience APIs for using HTTP and SSL together. This will come in one of the next releases, perhaps even before 1.0.

Things that are Known Missing

The cookbook section of the streams documentation has not yet been ported to Java, but the text of the Scala version applies to both languages. More documentation will follow in general, in particularly SslTls currently only has API docs.

The akka-http-core module is still missing the Java side of the multipart model (#15674). Working with HTTPS (client- and server-side) is not yet as easy as it will be. Additionally not all of the directives that make up the high-level server-side API in akka-http-scala have proper counterparts in akka-http-java (#16436). We will close these gaps shortly.

General Notices

The complete list of closed tickets can be found in the streams-1.0-RC1 and http-1.0-RC1 github issues milestones.

For the full stats see the announcement on the website.

The activator templates have also been updated:

Akka Streams with Java8!

Akka Streams with Scala!

We’d like to thank all of you for testing and for providing feedback on our progress.

Happy hAkking!

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[Patrik Nordwall]

The artifact name of akka-http-experimental_2.11 has been changed to akka-http-scala-experimental_2.11.

akka-http-testkit-experimental_2.11 changed to akka-http-testkit-scala-experimental_2.11.

Same with the _2.10 artifacts. Sorry that we missed that in the announcement.

/Patrik

On Fri, Apr 24, 2015 at 11:04 PM, Magnus Andersson <magnus.a...@mollyware.se> wrote:

By the way

These packages seems to be missing:

com.typesafe.akka:akka-http-experimental_2.11:1.0-RC1

com.typesafe.akka:akka-http-testkit-experimental_2.11:1.0-RC1

Looked at the Maven repo and RC-1 were not present:

https://repo1.maven.org/maven2/com/typesafe/akka/akka-http-experimental_2.11/

https://repo1.maven.org/maven2/com/typesafe/akka/akka-http-testkit-experimental_2.11/

/Magnus

Den fredag 24 april 2015 kl. 22:47:07 UTC+2 skrev Magnus Andersson:

Very nice work! Excited to get started.

I was asking about TLS for akka-http just a few hours ago in another thread. Really hoping you manage to squeeze the high level APIs into 1.0. 

In the mean time, are there some examples of SSL+HTTP (HTTPS) for client connections? I don't mind using streams and switch it out later when APIs become available.

/Magnus

--
>>>>>>>>>> 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.

[Konrad Malawski]

Thanks for pointing that one out!

I fixed the page: https://github.com/akka/akka.github.com/pull/196

Thanks again and happy hakking!

-- konrad

W dniu niedziela, 26 kwietnia 2015 14:13:32 UTC+2 użytkownik Anton Kulaga napisał:

>akka-http-testkit-experimental_2.11 changed to akka-http-scala-experimental_2.11.

Thanks for the clarification. Could you please update http://akka.io/docs/ as there are names without "scala" suffix there.

[Johannes Rudolph]

Hi Anton,

On Sun, Apr 26, 2015 at 9:31 PM, Anton Kulaga <anton...@gmail.com> wrote:
> What about Websockets, as I understood they are supported in RC-1 but is
> there anything in documentation that explains how to use them in akka-http?

Server-side websocket support is included in RC1 but not yet
documented. An example usage of the low-level API can be seen here:

https://github.com/akka/akka/blob/release-2.3-dev/akka-http-core/src/test/scala/akka/http/scaladsl/TestServer.scala

In the high-level part a new directive `handleWebsocketMessages` is
now available, see

https://github.com/akka/akka/blob/release-2.3-dev/akka-http-scala/src/main/scala/akka/http/scaladsl/server/directives/WebsocketDirectives.scala

We'll add proper documentation asap.

Johannes

[Jakub Liska]

Hey,

shouldn't the :

Flow#mapAsync(parallelism: Int, f: Out ⇒ Future[T]): Repr[T, Mat]

method have this signature :

Flow#mapAsync(parallelism: Int)(f: Out ⇒ Future[T]): Repr[T, Mat]

as scala collection foldLeft, so it could be called like : 

Flow[Resource].mapAsync(4) { res => asyncCode }

It is always a drag to call methods with function argument if multiple arguments are present...

[Jakub Liska]

I'm deconstructing the argument on like 20 places in my application :

flow.mapAsync { case res :: errors :: result :: HNil =>  ... }

and now pattern matching will have to be used everywhere for the argument to be deconstruced ... this interface is really unfortunate

[Roland Kuhn]

I'm on the phone right now and might be missing something but shouldn't the following work?

.mapAsync(4, { case …})

Regards,

Roland 

Sent from my iPhone

--

[Roland Kuhn]

More reasoning (but please correct me): for foldLeft the curried argument list is needed in order to fix the function’s input type which would otherwise need to be specified explicitly, plus it allows infix operator notation (which is desirable for consistency with the :\ operator). Neither of these arguments apply to mapAsync AFAICS.

Regards,

Roland 

Sent from my iPhone

[Endre Varga]

I have to admit that I prefer the curried argument list in this case. It reads more DSLly:


   .mapAsync(parallelism = 7) (do stuff)

-Endre

--
You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.

[Odd Möller]

Another reason to prefer the curried argument list in this case is to allow the following style:

   .mapAsync(parallelism = 7) { res =>
     ...
   }

and:

   .mapAsync(parallelism = 7) { 
      case ...
   }

The Scala Style Guide mentions it here: http://docs.scala-lang.org/style/declarations.html#higher-order-functions

Greetings

Odd

[Reid Spencer]

I too would prefer to see the curried style used for the reasons @Odd mentioned. 

[dario...@me.com]

+1

On 28.04.2015, at 12:10, Reid Spencer <re...@reactific.com> wrote:

I too would prefer to see the curried style used for the reasons @Odd mentioned. 

--

[Jakub Liska]

Roland you are right with the arguments applying to foldLeft only, but this is just a syntactic matter. MapAsync is one of the most frequently used stream combinators and the streams would loose readability significantly like this ... 

[Konrad Malawski]

On a personal style-preference note I’m with Jakub here.

While not specifically required for inference or things like that, it does read/write itself nicer with 2 parameter lists.

-- 

Cheers,

Konrad 'ktoso’ Malawski
Akka @ Typesafe

--
You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.

[Carsten Saathoff]

+1

It definitely reads better with curried arguments.

best

Carsten

[Roland Kuhn]

Oliver: personally I’m with you on this one, for me there is no big difference between the two, but since the Scala style guide recommends one of them I prepared a PR.

Jakub: thanks for raising this point—even though personally I don’t see how the RC1 version was less readable (the difference is exactly one comma and the placement of the closing parenthesis) I see value in following established style guidelines.

everyone else: thanks for the feedback!

28 apr 2015 kl. 14:20 skrev Oliver Ruebenacker <cur...@gmail.com>:

     Hello,

  Sorry, I don't see how this:

.mapAsync(parallelism = 7) { res =>

     ...

   }

  is any better readable than this:

.mapAsync(parallelism = 7, { res =>

     ...

   })

  The second makes it more obvious that the {...} block is part of a method call.

     Best, Oliver

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Oliver Ruebenacker

Solutions Architect at Altisource Labs

Be always grateful, but never satisfied.

--
>>>>>>>>>> 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.

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn