Allow for third-party routing logic to tap into the Tapir backends

Hi there 👋 I'm the creator/maintainer of smithy4s, a scala toolset around the smithy IDL.

Smithy4s provides a code-generator that creates protocol-agnostic and third-party-library-agnostic scala code, with a number or abstractions that allow for implementing integrations with various protocols and libraries. Out of the box, it provides an integration with http4s. Internally at $work however, it contains a few more integrations with, in particular, other http libraries.

In essence, smithy4s does some things that are pretty similar to what Tapir does under the hood : when using it server-side, it turns a "front-end" (which comes in the form of domain-specific generated interfaces that users implement) into some routing logic that produce a HttpRequest => Option[F[HttpResponse]], that can be wired to a third party http library to translate that into some router construct specific to that library.

So the fact that smithy4s comes with an http4s integration out of the box doesn't imply that the generated code produced by smithy4s is biased towards a specific flavour of Scala : smithy4s can be used with direct-style scala, cats-effect, zio, scala-futures, etc.

Thing is, we don't have the resources to provide integrations with a similar number of libraries to what Tapir does. I do believe however that with rather small, backward-compatible changes to Tapir, it'd be possible for Tapir to allow third-party front-ends (like Smithy4s) to integrate with its many back-ends.

The POC

Rather than doing a lengthy description, here's a POC

• what the changes in Tapir would have to look like to support third-party front-ends : https://github.com/Baccata/tapir/pull/1/files
• demo showcasing a smithy4s service running on the tapir backend for jdkhttp : https://github.com/Baccata/smithy4s-tapir-poc

(NB : the demo is using smithy4s-deriving, an experimental library for code-first smithy4s, but it proves that it'd work for smithy4s itself)

Devil's advocate thoughts

I like poking holes into my own ideas so here you go :

Would it be desirable for Tapir maintainers to allow for this, when it essentially helps what could be seen a competing product ? Well, I honestly don't know. The way I see it, I don't think Smithy4s and Tapir are directly competing with one another : Smithy4s aims at offering a smithy-centric, highly focused developer experience that hides the intricacies of protocols away from the users, letting them focus on domain-specific concerns in a rather constrained way. In the case of http, this comes at the cost of not allowing to tap into everything that http allows for, as the notion of "protocols" in smithy equates bounded sets of semantics that facilitate the implementation of inter-compatible SDKs.

Tapir has two main axes of value :

1. the endpoint DSL (front-end), that provides a sane way to users of tapping into as many HTTP semantics as possible
2. integrations with virtually all http libraries from the java and scala ecosystems (back-end).

I personally think that the decoupling of those two axes is valuable, in a similar way that the LSP is valuable to decouple language support from edits. A similar decoupling is present in Smithy4s, which has allowed for smithy4s-deriving to see the light of day. Not sure anyone will actually use it, but the possibility is interesting in itself.

Note to the Tapir maintainers :

If the maintainers decide the change is not desirable, I totally respect that 😄. I understand the cost that comes with being an open-source maintainer and I understand that wanting to set a certain direction for the project means saying no to people asking for things.

Thank you for reading, and for your consideration.