Chunked response limitations

[lpil]

Hello!

The chunked response body type is using the yielder type to represent a stream of data instead of the BEAM standard approaches of using messages or a side effecting chunk sending function.

It seems like this yielder based approach has some drawbacks:

It blocks the request handling process, causing the OTP functionality such as system messages to no longer work while the response body is being computed. For sure lived processes that immediately send a response that's expected, but during long lived ones it would benefit from these features working, the same as the SSE and websocket ones seem to.

The non-message based API means that programmer will need to work out how to translate from the messages producing the stream of data into the yielder.

In the event of an error there's no way to propagate that error to the client by aborting the request, instead the only option is to discard the error and successfully finish the stream.

The other 2 streaming modes (websockets and server sent events) use a more conventional message based API that don't have these limitations. To me it seems that consistently using the same API for all the streaming modes could remove these problems, and possibly make the library more approachable by reducing the number of things the programmer has to learn. Perhaps it would be worth migrating chunked responses to that design? Or might there be some other that design without the problems of yielder?

Thanks,
Louis

[rawhat]

Yep, that makes sense to me. I will look into this. When we talked about this a while ago, you agreed (at the time) that this was maybe the best solution. But obviously things have changed since then 😅

[lpil]

Ewe had a similar thing and has since unified all the streaming APIs, might be a good reference