How to use streaming methods with cats effect? (IO, fs2.Stream)

[efim]

I am trying to describe a service with server streaming operation
the smithy file looks like that:

service SimpleAutomoderation {
        operations: [  SubscribeToRoom ],
}

operation SubscribeToRoom {
          input: SubscribeToRoomRequest,
          output: SubscribeToRoomReply
}
@input
structure SubscribeToRoomRequest {
          @required
          roomId: String,
}
@output
structure SubscribeToRoomReply {
          id: Integer,
          state: BasicStateStream
}

@streaming
union BasicStateStream {
       state: BasicState,
       another: Unit,
}

And smithy4s seems to know that the response is streaming, judging by the type:

trait SimpleAutomoderationGen[F[_, _, _, _, _]] {
  self =>

  def subscribeToRoom(roomId: String) : F[SubscribeToRoomRequest, Nothing, SubscribeToRoomReply, Nothing, BasicStateStream]
}

But do I then try to instantiate server \ client with Stream[IO, ?] type?
the "response case class" only has the "non-streaming" attribute:

case class SubscribeToRoomReply(id: Option[Int] = None)

I'm not sure how to access / declare type for the streaming part and couldn't find anything in the documentation or repository.

Is that supported right now?

[Baccata]

Hi @efim. As you may have guessed, the tl;dr is that streaming-aware interpreters are not currently available.

One could certainly implement such interpreters in userland without smithy4s having to change, as all the required information that would allow to support this usecase is already available in the generated code, but implementing interpreters does require the implementor to be comfortable with quite non-trivial, high level abstractions that are currently undergoing significant changes (for the better : we're aiming to simplify a little bit some of the concepts to make it easier for folks to implement interpreters).

We'd certainly appreciate external contributions to move the needle on this usecase, but the code is not simple, and we still have to finalise some changes before we're comfortable with documenting the underlying abstractions to make smithy4s more contribution-friendly.

the "response case class" only has the "non-streaming" attribute:

I gave an answer about why that is the case there. We're not quite certain what the UX will be for implementing streaming-aware services yet, but the unary response elements and the streamed response elements have to be separated because we cannot have the generated case classes depend on cats.effect.IO (nor fs2.Stream for that matter).

Also, I cannot promise a timeframe on implementation, unfortunately. Our focus is currently on preparing for the release of the version 2.0 of the smithy IDL (which should arrive in the next few weeks). This new version retains backward compatibility with version 1.0 specs but adds some interesting features that we want to expose in our tools (smithy4s included). We're also preparing the release of some separate tooling to facilitate conversion of openapi specs to smithy.

There you go. I'm sorry I cannot offer better news, smithy4s is a work of passion and we feel very lucky that our employer
, DisneyStreaming, has agreed to sponsor it, but the team that maintains it has plenty other responsibilities, and we have to prioritise features based on the needs of our internal teams.

However, if you, or anyone, is interested with contributing, we'll very happily look at PRs 😄