4 ms·
I think there has to be massive benefit to the Rails community before there can be a consideration of adding such a feature. I could be wrong here, but I'm not
by rajangdavis 5y ago
I think there has to be massive benefit to the Rails community before there can be a consideration of adding such a feature.
I could be wrong here, but I'm not sure it will solve some of the more drastic issues of what happens in a production Rails app which I believe to be mostly around memory and garbage collection (from my limited experience and understanding).
You might be able to eke out more performance in terms of having more clients be able to hit a page, but I suspect that might make memory more of an issue, not less.
- joelbluminator 5y agoHow about ActionCable though? That's a big one I'm wondering about with Fibers/Async
- rajangdavis 5y agoNo clue... I could be wrong, but the underlying technology for ActionCable is Web Sockets and I'm not sure what problems async would solve there.
- joelbluminator 5y agoI'm guessing the Rails implementation for the webs sockets part is thread-based and if that's the case fibers can make a big difference. But I'm also a bit out of my depth here.
- kovacs 5y agoI think what's being talked about here is the back end implementation for ActionCable. By default it uses ruby threads to push over open web sockets. There's at least one production quality drop in implementation (https://anycable.io/ https://anycable.io/) that address the default scalability issues you'll have with ActionCable. The async support would seem to allow one to go much further with default rails before needing to move to something more performant.
- jrochkind1 5y agoThe problem it would solve is a back-end process handling multiple Web Sockets connections, efficiently.
- brunosutic 5y agoAsync has async-websocket gem. I don't have experience with it so can't tell how it compares to ActionCable. https://github.com/socketry/async-websocket https://github.com/socketry/async-websocket