zio
Reorg driver layers
modify Server layers such that they expose the Driver, this is required in order to be able to share resources between http server and client in the same application.
see this thread with @987Nabil to understand the motivations and considerations for this change.
This change is unfortunately a breaking change, however fixing the broken code is rather easy as can be seen in RoundtripSpec.
@987Nabil and myself mentioned few more options for achieving this, without introducing a breaking change:
- introduce layers that return
Server & Driver, this has the down side of creating a confusing API, furthermore if we ever get to deprecate the old layers we'd end up with an awkward API. - introduce layers requiring
Driverin their input environment. (same consideration re. API clarity) - add member to
Serverexposing theDriver, this way it'd be quite easy to craft layers that bootstrap a client from a server.
@987Nabil I recall now I had another issue related to the public layers 'hiding' the driver, my application used to expose two ports: one for service and one for management, seems like attempting this with zio-http requires two distinct server instances, unlike akka-http where we had a single actor-system happily serving both ports (via akka-http). I was able to overcome this by prefixing and moving the management routes to the service port (now known as the application port) but it required some changes to routes to make sure we're not exposing secrets through the svc port (i.e. an endpoint exposing the cfg). I think a better solution would be providing public layers exposing the dependency on the Driver, allowing users to compose them in order to share one driver for multiple ports and clients.