Look Ma, No Sidekiq: A peek into async future
summary
Converts blocking external API calls into concurrent IO so web requests no longer tie up Puma threads: demo load tests show Puma with 1 worker/5 threads suffers long queue latency when one-in-five requests blocks, while switching to Falcon (request-per-fiber) keeps short latency and all requests finish concurrently. Uses the async gem (fiber scheduler) and Turbo Frames to render a skeleton then replace it with fetched data. Works for IO-bound tasks only; CPU-heavy work still needs explicit fiber.yield and DB connection-pool care.
AI-written summary · about
chapters (7)
- 0:00Introduction and context
- 1:04The problem with thread-based I/O
- 5:15The async gem explained
- 7:31Falcon web server
- 9:27Turbo frames and async
- 13:29Limitations and deployment
- 16:12Q&A session
related talks
23mLook Ma, No Background Jobs: A Peek into the Async Future
33mAsynchronous Rails
38mHigh Concurrent Ruby Web Development Without Fear
43mTurbo Boosting Real-world Applications
56mRails 4 and the Future of Web
36mFrom Request To Response And Everything In Between
43mDataflow: declarative concurrency in rails
39mAsynchronous Workers to the Resque