WebSocket Client: `WebSocketApp` runs in its own fiber, but should it?

[mberndt123]

Hi there,

The socket method to connect to a WebSocket server is declared like this:

  def socket[Env1 <: Env](
    app: WebSocketApp[Env1],
  )(implicit trace: Trace, ev: ReqEnv =:= Scope): ZIO[Env1 & ReqEnv, Err, Out] =

The way it works is that ZIO-HTTP tries to establish a WebSocket connection, and if that succeeds, it will fork a fiber that the WebSocketApp is going to run in and return the response to the WebSocket request. https://github.com/zio/zio-http/blob/a2e87276ae39558100346b30b81e4bdcf8450b6a/zio-http/jvm/src/main/scala/zio/http/netty/client/NettyClientDriver.scala#L133

It isn't obvious to me why the forking is required, and it makes some very simple use cases inconvenient to implement. For example, to simply run the WebSocketApp until it's done and have it return a result, I need to create a Promise, create a WebSocketApp that will complete that promise, pass that to the socket call, and then wait for the completion of the promise. And it's even worse when I want to create a ZStream from a WebSocket, now I need to create a Queue to pass the data around between fibers and it's just a hassle in general. So my question is: wouldn't it be much simpler to just return the WebSocketChannel from the socket call? Then I can do with it whatever I like, including forking.

[987Nabil]

Websocket needs a redesign for 4.0 anyway. Will keep this open for tracking