MEGA ticket for Akka Http backend related tickets

[2m]

Work-in-progress branch and PR can be found here: #205

List of topics that are currently missing:

• WSClientConfig support for akka-http backend #213 configuration
• Proxy support for akka-http backend #214 proxy support when using HTTP Add support for HTTP proxy servers on the client side akka/akka-http#115
• Follow redirects support for akka-http backend #215 follow redirects Add automatic redirection handling akka/akka-http#195
• Improve timeouts supports for akka-http backend #216 proper request timeout support. Now it is implemented using future timeouts. Add request timeout support to client-side pool APIs akka/akka-http#42
• Caching support for akka-http backend #217 caching support
• Signature calculator support for akka-http backend #218 signature calculator support
• authentication
  • BASIC
  • DIGEST authentication support for akka-http backend #219 DIGEST
  • NTLM authentication support for akka-http backend #220 NTLM
  • SPNEGO authentication support for akka-http backend #221 SPNEGO
  • KERBEROS authentication support for akka-http backend #222 KERBEROS

[ktoso]

Can we split this out into separate tickets and tag with "akka-http-backend"?

[2m]

Sure. Do you have powers here to create the label?

[ktoso]

Oh, perhaps not (neither do I), plz help @richdougherty @gmethvin ?

[gmethvin]

just added you as collaborators

[ktoso]

Thanks!

…

-- Cheers, Konrad 'ktoso <http://kto.so>' Malawski Akka <http://akka.io/> @ Lightbend <http://lightbend.com/> On January 2, 2018 at 21:40:47, Greg Methvin ([email protected]) wrote: just added you as collaborators — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#207 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHYk5Iz9sWYdp8HHE0rIqDbIQ6vXYB7ks5tGpRMgaJpZM4RFafc> .

[2m]

Created a project board for the akka-http backend and created tickets for all of the points in the list.

[patriknw]

Note that the above list is to get feature parity with existing WS, then more features can be added, such as support for http/2 and websockets.

[gmethvin]

In terms of importance I'd say:

1. configuration, so it's a drop-in replacement for an existing configured client. Initially you could throw exceptions for followRedirects and any unsupported options.
2. follow redirects
3. signature calculator support
4. proxy support
5. caching support (this is a newer feature)
6. other forms of authentication (Basic is probably good enough for many cases)
7. proper request timeout support (though I admit I don't understand the true implications behind the way akka-http does it now)

This is roughly based on my perception of how popular features are, but it might also make sense to tackle "easier" things first (based on your judgement) so we can get something usable sooner. We also might want to look at which features Lagom needs so we could start using it there initially before everything is done. @TimMoore wdyt?

@marcospereira might also have opinions.

[TimMoore]

I know Lagom uses WSClientConfig. Other than that, I don't know if anything from this list is more important than the others.

[patriknw]

@TimMoore You mentioned that Lagom is internally using a subset of the Play WS. Could you list which of the features from the above list that is used in Lagom, and we could perhaps start with those.

[2m]

For the next three days, I am going to be working on features from this list. I will start with WSConfig.

[TimMoore]

Sorry for my unresponsiveness. I had to do a bit of investigation into how Lagom uses WS since I haven't really touched that part, and it got shelved until after 1.4.0 was released.

The way Lagom uses WS is really simple. It doesn't seem to override any default configuration.

The way it uses WSClientConfig is only to pass through a configuration that is explicitly loaded using Play's default configuration loading mechanism in the LagomClientFactory. So it's not passing in any special hardcoded configuration. LagomClientFactory is intended for use in Java application that are not based on Play or Lagom, for building a service client in an environment that doesn't have the usual Guice module system. It was originally written to use Play WS before the standalone version existed, so it brings in a Play dependency. It should probably be refactored to use the standalone version now. That's something we can do.

It doesn't specifically rely on anything else from that list, but it's harder to say how it's configured and used by people developing Lagom services. Anything that can be configured in application.conf could be potentially enabled in a Lagom service. And for example, whether following redirects is required depends totally on how people have implemented their services.

So I think it's fine to ship an early, experimental opt-in implementation that doesn't have all (or any) of these features as long as people have the ability to keep using the async-http-client based version if they need to.

Right now, here's how Lagom chooses a WSClient implementation:

• In Java services, it is injected by the Play module system, which is based on whatever is available on the classpath. The Lagom client module has a direct dependency on play-ahc-ws, so we'll need to change that and make users add a dependency to the implementation they want to use.
• LagomClientFactory (used in non-service Java applications) explicitly hardcodes the AhcWSClient implementation.
• In Scala, you also need to explicitly mix the Components trait for the implementation you want into your application.

So if the Akka HTTP implementation implements the same interfaces, then it should be easy to make things configurable with a small amount of work in Lagom. I recall some discussion that the new implementation may not be API compatible, in which case we would need to add an additional layer of indirection to Lagom to make the implementation configurable.