Mounting a smithy4s generated route on a path

[ShahOdin]

So with http4s I can do:

val myRoutes: HttpRoutes[IO] = HttpRoutes.of(
  case GET -> Root / "hello" / name => Ok(s"Hello, $name!")
)
val myHttpApp = Router("v1" -> myRoutes)

and that should make the route available at /v1/hello/$name. I'm trying to do this with a smithy4s generated route and I am not having much luck. This is my code:

private val routes: Resource[IO, HttpRoutes[IO]] = ???
private val docs: HttpRoutes[IO] = smithy4s.http4s.swagger.docs[IO](CrowdFlexApiGen)

val app: Resource[IO, HttpApp[IO]] = routes
  .map(_ <+> docs)
  .map(r => Router(s"/${"2.0"}" -> r))
  .map(_.orNotFound)

I can navigate to the swagger docs successfully via: http://localhost:9000/2.0/docs/ but:

• the generated swagger doesn't know it's technically mounted at http://localhost:9000/2.0 rather than http://localhost:9000. so the requests fail.
• hitting the routes directly via curl don't return me any results either.

Not sure if this is me not understanding http4s properly or if these are bugs by smithy4s.

the actual use case I have is this:

The server paths will be provided by the [api providers]. Note that we will version the URLs to align with the schema version number.

I have described it here: smithy-lang/smithy#2233 now on reflection, perhaps this api prefix should be kept off the api specs and not included in the smithy specs and the issue linked above isn't the way to do it, but I'd like to know how to have my service that is generated via prefix-free smithy specs, mounted with a prefix.

For now, I have resorted to hardcoding the version prefixes in the smithy definitions themselves but I feel like there must be a better way!

[ShahOdin]

p.s. in the example provided above, as is, what would be the path to get to my route? 😕

[kubukoz]

Looks like #152 - the Router part makes it, well, not work.

If your smithy specs already contain a version prefix, you don't need to put a Router on top of them.

[ShahOdin]

If your smithy specs already contain a version prefix

yeah it's what I have settled on for now (so yeah won't need it) but Ideally I'd like to not have the prefix baked in. sounds like you're saying that's not a possibility. 😞

[ShahOdin]

if SimpleRestJsonBuilder doesn't work well with the http4s Router as suggested by #152 I feel like SimpleRestJsonBuilder should take a mountAt parameter defaulting to /:

• with the routes taking that into account
• swagger docs respecting that prefix too

[kubukoz]

It's not with Router, but I think it could be made possible with a custom implementation - pathInfo vs path, a custom router using the same thing smithy4s uses might do the trick.

However, that only makes it work on the server. A smithy4s client would need to be modified in a similar way in order to work with your service, and at this point you're implicitly defining a new protocol.

At this point I'd say you should either commit to the "separate protocol" idea (so use something that isn't exactly simpleRestJson, btw this is what we're doing internally in $job), or maybe apply some model preprocessing to add the version prefix automatically before code generation: https://disneystreaming.github.io/smithy4s/docs/guides/model-preprocessing/

[ShahOdin]

A smithy4s client would need to be modified in a similar way in order to work with your service, and at this point you're implicitly defining a new protocol.

To counter balance your point smithy-lang/smithy#2233 (comment) this is what smithy-lang folks had to say:

Lots of services need a prefix when they deploy their service. One reason might be that they run multiple services from the same host and disambiguate based on a base path. In these cases, the prefix isn't really part of the API itself but rather part of where the API is hosted.