From what I was able to tell (I followed the discussion around this) enabling Rails to work with Async is not huge amount of effort. One guy was working on this, but he got distracted with other stuff.
It's just a matter of time someone steps up and gets this to work.
I imagine something more "native" to rails will happen eventually though. But would need to be after this makes its way into core ruby(which has not happened yet apparently).
The only caveat is that it doesn't work with Ruby on Rails, because ActiveRecord doesn't support async gem. You can still use it with Rails if ActiveRecord is not involved.
I don't understand. Is this misleading then? Did HTTParty have to implement Async for their example to work?
> You probably have your preferred HTTP gem, and you may be asking "will it work with Async"? To find out, here's an example using HTTParty, a well-known HTTP client.
They then go to show that your "preferred HTTP gem" will just work. How is the ActiveRecord situation different?
You're not wrong. If you have external services that are accessible via HTTP, there is some potential to get some performance gains there. You're just limited in terms of some of the core Rails utilities.
It does it with threads though, which has implication when we talk about moderate/big traffic and Action Cable. A big win would be if Action Cable will be able to work with Fibers/Async or something equivalent. It's an annoying performance bottleneck and it would be super awesome if Ruby/Rails just solves it.
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.
I 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/) 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.
I'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.
Does anyone know plans around how this will be implemented into Rails?