Materializer/ActorMaterializer confusion

Akka
1

Hey guys, I’m using the drunk library for graphql queries and its constructor is like this:

object AkkaHttpBackend {
  val ContentTypeHeader = "Content-Type"

  def apply(
    uri: Uri,
    headers: immutable.Seq[HttpHeader] = Nil,
    httpExt: Option[HttpExt] = None
  )(implicit as: ActorSystem, mat: ActorMaterializer): AkkaHttpBackend = {

    val http = httpExt.getOrElse { Http(as) }
    new AkkaHttpBackend(uri, headers, http)
  }
}

My question is, how do I provide an ActorMaterializer to it?

Thanks to the deprecation, I do have an instance of Materializer, but how do I get an instance of ActorMaterializer from that?

In general, how should I use a library which is expecting an instance of ActorMaterializer and not of a Materializer?

2

That ActorMaterializer is deprecated does not mean it is gone, you can still create one with the same old ActorMaterializer.apply factory methods as before and pass it to the third party library.

Deprecation however means that ActorMaterializer will be gone after a full minor version life cycle of Akka (so in 2.7) so to keep working with future versions of Akka the library should update to not rely on the deprecated ActorMaterializer and start using Materializer or pick up the system Materializer instead.

3

The library depends on akka-http, which has not yet upgraded to akka 2.7. More precisely, it depends on akka-http 10.1.x, which is still depending on akka 2.5

That said, the term system wide materializer sounds like a singleton, whereas if I create my own ActorMaterializer, it won’t be a singleton. So should I be trying to make it a singleton using my DI framework?

4

Yes, that it is a single materializer for the entire system is one of the improvements. Having another one (that you share between invocations) for that library will not be a big problem though. Important to not create many of them and that their lifecycle is managed, so you should remember to stop it if you are done with it though. You can read more in the docs here: https://doc.akka.io/docs/akka/current/stream/stream-flows-and-basics.html#actor-materializer-lifecycle

That Akka HTTP depends on 2.5 is more of a lowest bound, since we maintain backwards binary compatibility it should be fine to override those transitive dependencies to a newer version of Akka (not however that all Akka modules pulled in must be of the same version)