Evented Ruby vs Node.js
summary
Claim: you can get Node.js-style concurrency while staying in Ruby by running a reactor and making IO libraries reactor-aware. Add a reactor with EventMachine (or use thin/rainbows), wrap each Rack request in fibers with rack fiber pool, convert blocking adapters with em-synchrony or configure Faraday to use an EM adapter, and use em.defer or EM.popen for stubborn blocking work. Fewer processes and lower memory follow, but library patching and a smaller community are real costs.
AI-written summary · about
chapters (13)
- 0:00Introduction to performance
- 2:51Understanding evented design
- 3:53Non-blocking IO explained
- 7:50Node.js versus Rails model
- 9:43Optimization strategies
- 14:19Latency versus concurrency
- 16:16Ruby reactor implementation
- 18:28Handling blocking IO in Ruby
- 21:30Using fibers for concurrency
- 25:02Applying fibers to Rails
- 28:42Libraries for evented Ruby
- 32:55Pros and cons of evented Ruby
- 36:22Conclusion and takeaways
