Exposing Handler in zio-http

tapir
1

I was wondering the motivation behind exposing an HttpApp only in the ZioHttpInterpreter and not a Handler version as well (which is already existing as an inner method tapir/ZioHttpInterpreter.scala at bc77e64c266c2c1eb9adc8f9281fb5327140a44e · softwaremill/tapir · GitHub)

I know that zio-http went into a lot of refactoring and breaking changes recently, so I would not mind opening a PR to add that to tapir, but I wanted to know if there was a reason for that first ?

My idea behind that is that Handler are a bit more composable than Http (we have a Flatmap on them), and that it could be worth exposing a way to retrieve handler from Tapir.

WDYT ?

2

There’s no reason that I’d be aware of. Probably it was just created this way :slight_smile: If there’s a more general concept that we could interpret into - let’s do that. Either as a replacement, or as a complementary API.

3

Ok thanks, I will either wait or work on the upgrade to the zio-http 3.0 release candidate and might introduce another method on tapir to retrieve an Handler instead, however they fixed the application of middleware in zio-http and we can now apply Handler middleware on HttpApp so there is less need for such a method yet

4

Yes, we need somebody to migrate to latest zio-http :slight_smile: See also: [BUG] ZioHttpInterpreter constructor fails at runtime (for zio-http 3.0.0-RC1) · Issue #2846 · softwaremill/tapir · GitHub

5

A release supporting zio-http 3.0.0-RC1 is now available: Release v1.2.13 · softwaremill/tapir · GitHub

If you think the integration would need some adjustments, it would be great to capture these as an issue or PR - thanks :slight_smile: