3 ms·
It's an interesting approach. It's only async from the client perspective though. Right? The server still processes the action/render inline? (i.e. it's not spa
by gingerlime 9y ago
It's an interesting approach. It's only async from the client perspective though. Right? The server still processes the action/render inline? (i.e. it's not spawning a sidekiq process as far as I can tell).
We recently implemented something that's async on the server, using a combination of pusher and sidekiq. This was particularly useful for cases where we access an external API and don't want to hold the unicorn process for too long. So when the response comes back we push it back to the client and display it. Would be interesting to maybe combine this approach with some server-push and background workers and what this gem is doing.
- kawsper 9y agoRender-async lets the client render the page, and then request "partials" from the server, the backend sees two different requests from the browser The inline includes that Varnish does is synchronous for the client, but asynchronous in your backend, your backend sees multiple requests. I am interested in your pusher+sidekiq implementation, it is a good idea, but it might be a lot of work :)
- gingerlime 9y agoIt's definitely more involved, and might be slightly more complex to generalize, but in essence it's quite straight-forward: 1. Client sends a request via Ajax to a rails controller and simultaneously opens a private pusher channel to wait for a response. 2. Controller returns a response immediately and fires-off a sidekiq job. 3. The sidekiq job does the heavy lifting and pushes the results back via pusher (it can be JSON data, or a rendered partial). 4. Client receives the response via the pusher channel and shows it on the page.