4 ms·
How about ActionCable though? That's a big one I'm wondering about with Fibers/Async
by joelbluminator 5y ago
How 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