The problem with this approach is that you need to sit with the response in memory while you undo the stack. If you have a pipeline with 10 plugs, it is most likely that only one or two need to modify the response. In Plug you would register callbacks when you need it. In the Rack model, you need to hold all 10 middleware in the stack.

I would also argue that the use of Plug is simpler for the majority of cases. You can’t get simpler than a single function that receives the connection and returns the connection. As an example, in Phoenix you can use plugs both as “callbacks” in your controller and in your pipelines. However, in Ruby, almost all frameworks and libraries, such as Rails and Sinatra, end-up introducing a new lightweight abstraction that resembles Plug, such as callbacks or filters at the controller and application level.

However, I definitely agree the Plug model is more complex than the Rack model in the scenarios you mentioned. Part of the problem here, especially in regards to exception handling, was that the issue was discovered as we moved forward due to the interplay between Plug and immutability. I believe it would be less confusing if those issues could have been articulated up front.

That’s not saying Plug is the ideal interface for everything but for HTTP the list of pros fairly outweigh the cons (IMO ), especially with HTTP 2 being available and playing even more on the strengths of streaming, data push, multiple responses, etc.

Found this talk, not sure if it’s up to date but here it is anyway:

Personally I think exploring new ideas is always a good thing, choices generally drive innovation.

Can’t believe it took me this long to find this paper “Your Server as a function”

Operations are phrased as value transformations,encouraging the use of immutable data structures and, we believe,enhancing correctness through simplicity of reasoning.

While most of our engineers find the programming model un-usual, they tend to internalize it quickly.

The whole paper is discussed in a Scala/Java context so some parts don’t translate well, e.g. there is no need to talk about Futures. However it is interesting to see some of these ideas explained more rigorously than I ever managed when talking about Raxx.

There is also a discussion about interrupting ongoing processing, for example in the case of a timeout.
This is an equivalent here, in Elixir/Erlang. e.g. a Gen call can timeout, but the processing will continue and the reply potentially be returned to the mailbox later.

Is anyone sending interrupt message to processes in the case of a call timeout.

Finally the paper is in a typed language. The idea of statically verifying that only authenticated requests are passed to a service(http handler) that requires authentication is very appealing.
Although less easy to see how this can be useful in Raxx, it might be useful to Midas,
https://github.com/midas-framework/midas