"Why your web framework should not adopt Rack API" by José Valim

http://blog.plataformatec.com.br/2012/06/why-your-web-framew...

"This blog post is an attempt to detail the limitations in the Rack/CGI-based APIs that the Rails Core Team has found while working with the streaming feature that shipped with Rails 3.1 and why we need better abstractions in the long term."

I was more meaning top to bottom, although I confess I never looked into the feasibility of just rolling my own thing with rack. I should have clarified what I was looking for, which was an event-based micro web framework.

Event machine is what's underpinning cramp, which is what I went for, and it does the job ok. The problems I had were to do with less than full support from the top to the bottom of the stack (basically the only server I could use was Thin, and there was no way to get anything working with Torquebox that I could find)

> Your Rails application can only have as many clients total as you have workers if they all keep a permanent connection.

So even though it's event-based, if I have 1000 clients long-polling (or SSE'ing, or whatever) that would tie up all my workers? I may have misunderstood what we were getting in Rails 4, then.

Rack 1.x doesn't have end-to-end streaming, and certainly not with a socket-style API. The Rack specification mandates buffering and rewinding input, and while it's possible to write a rewindable input stream (I've actually seen it done) nobody has ever written a stable one.

EventMachine is poorly maintained and doesn't have the same level of community support as Node.js, not to mention an ugly API. Of course, Node.js doesn't have the same level of maturity as Twisted Python but Twisted doesn't get any hype whatsoever.