"Service pattern 2.0", how to "hide" implementation specific dependencies from service interface

[artur-jablonski]

I bumped into this scenario and I am not sure how to structure the code around it.

Say you have a workflow that depends on A

object workflowThatNeedsA {
  val layer: ZLayer[Any, Nothing, A] = ???

  def doStuff: ZIO[A, Nothing, Unit] = ???
}

You also have a service that follows the "service pattern 2.0"

1. A trait:

trait MyService {
  def makeMeRich: ZIO[Any, Nothing, Unit]
}

2. Accessors:

object MyService {
  def makeMeRich: ZIO[MyService, Nothing, Unit] = ZIO.serviceWithZIO[MyService](_.makeMeRich)
}

3. Implementation that happens to use workflowThatNeedsA.doStuff in its internals

case class MyServiceImpl() extends MyService {
  override def makeMeRich: ZIO[Any, Nothing, Unit] = workflowThatNeedsA.doStuff
}

that won't compile because the signature has Any in environment, but the return type has A.
So I changed the type signature for them to align:

case class MyServiceImpl() extends MyService {
  override def makeMeRich: ZIO[A, Nothing, Unit] = workflowThatNeedsA.doStuff
}

This won't compile because MyService trait has Any in the enviornment so compiler now is unhappy about that.
Ok, I will change the type signature on the trait then:

trait MyService {
  def makeMeRich: ZIO[A, Nothing, Unit]
}

oh and now the accessor is wrong, too, says the compiler. Ok, fine let me "fix it":

object MyService {
  def makeMeRich: ZIO[MyService with A, Nothing, Unit] = ZIO.serviceWithZIO[MyService](_.makeMeRich)
}

so now the compiler is happy so I just add my layer

object MyServiceImpl {
  val layer = ZLayer.fromFunction(() => MyServiceImpl())
}

and now it all works and I can run the workflow with

MyService.makeMeRich
.provide(MyServiceImpl.layer, worflowThatNeedsA.layer)

But this is not that great. I had to expose the implementation dependencies on to the interface. What if I have another implementation of MyService that requires some other dependency.... then it's all sad pandas everywhere again.

Ideally I would want to keep the interfaces and accessors clean, so the only place where this belongs to is in MyServiceImpl.layer.

However I am not sure how to convey the idea of satisfying dependency A inside the method implementations. I thought about doing this:

case class MyServiceImpl() extends MyService {
  override def makeMeRich: ZIO[Any, Nothing, Unit] = workflowThatNeedsA.doStuff.provide(workflowThatNeedsA.layer)
}

and that will, work. However this is still not what I want. Let's say that A is some very heavy object like connectionpool, threadpool, etc, that I just want to create once and reuse in my entire application, so I want to pass the layer from "end of the world".

If my code was directly depending on A then I guess I could do that:

case class MyServiceImpl(a: A) extends MyService {
  override def makeMeRich: ZIO[A, Nothing, Unit] = a.blah() //direct interactoin with `A` object
}

and then in layer

object MyServiceImpl {
  val layer = ZLayer.fromFunction(MyServiceImpl(_))
}   

but this is not the case. it's some workflow I use that needs that A.... What am I missing?

[adamgfraser]

@artur-jablonski You want to express A as a dependency of your service implementation like the below.

object workflowThatNeedsA {
  val layer: ZLayer[Any, Nothing, A] = ???

  def doStuff: ZIO[A, Nothing, Unit] = ???
}

trait MyService {
  def makeMeRich: ZIO[Any, Nothing, Unit]
}

object MyService {
  def makeMeRich: ZIO[MyService, Nothing, Unit] =
    ZIO.serviceWithZIO[MyService](_.makeMeRich)
}

case class MyServiceImpl(a : A) extends MyService {
  override def makeMeRich: ZIO[Any, Nothing, Unit] =
    workflowThatNeedsA.doStuff.provideEnvironment(ZEnvironment(a))
}

object MyServiceImpl {
  val layer: ZLayer[A, Nothing, MyService] = ZLayer.fromFunction(MyServiceImpl(_))
}   

You will notice that there is a slight amount of boilerplate here in having to do provideEnvironment(ZEnvironment(a)). This is a clue that A should really be a service:

trait A {
  def doStuff: ZIO[Any, Nothing, Unit]
}

object A {
  val layer: ZLayer[Any, Nothing, A] =
    ???
}

Then you can express your implementation of MyService like this:

case class MyServiceImpl(a : A) extends MyService {
  override def makeMeRich: ZIO[Any, Nothing, Unit] =
    a.doStuff
}

[artur-jablonski]

Aaaaah! It all makes sense now! Thank you for such quick response @adamgfraser

I guess what I totally missed is ZEnvironment and that you can construct it with ready values of dependencies unlike ZLayer that works on "recipes" to produce values.

... goes to change all method signatures