You can certainly work around it but the trade-offs of working around are very platform specific. For example, Node.js or Erlang apps do not need another infrastructure because streaming is in their foundation, there is no need at all for another stack. On the other hand, rack-stream forces you to use thin (so you can choose in having a specific stack or deploying it all together with thin).
In any case, the main point of the blog post is the amount of effort required in wrapping existing Rack middleware so they play along with streaming but still in a non-optimal way. For example, see the connection management middleware in Active Record:
Even more, if your rack-stream middleware is after the connection management middleware, each stream loop will first need to pass through the proxy call. The longer your stack, more proxies it will likely have and more cost will be involved in each stream.
So yes, you can work around but requires a lot of extra work and is not as efficient.
I disagree, the add-on I wrote, noir-async (which is really just sugar for noir + aleph), fully supports mixed streaming and chunked.
However, the reason I wrote that non-streaming endpoints should be separate apps is that their performance profile tends to be radically different, and you probably want those concerns separated.
In any case, the main point of the blog post is the amount of effort required in wrapping existing Rack middleware so they play along with streaming but still in a non-optimal way. For example, see the connection management middleware in Active Record:
https://github.com/rails/rails/blob/3-2-stable/activerecord/...
Even more, if your rack-stream middleware is after the connection management middleware, each stream loop will first need to pass through the proxy call. The longer your stack, more proxies it will likely have and more cost will be involved in each stream.
So yes, you can work around but requires a lot of extra work and is not as efficient.