Evented Ruby vs Node.js
summary
Argues Ruby can get Node-style concurrency without rewriting apps by using EventMachine reactors, per-request fibers (via rack-fiber-pool), nonblocking adapters (Faraday EM-sync) and em.defer for legacy blocking calls. Claims this raises per-process concurrency and lowers memory cost versus many Rails processes but does not reduce single-request latency. Gives a working example: a standalone zip generator Node process runs alongside Rails at GitHub to handle heavy IO and succeeds in practice.
AI-written summary · about
chapters (29)
- 0:00Intro
- 0:44Performance Goals
- 1:42Evented...
- 2:25Evented Programming
- 2:47Reactor Pattern
- 4:17Node.js
- 4:51Blocking 1/0
- 7:00Web Apps
- 7:58Rails Concurrency
- 8:58Node Concurrency
- 11:00Latency
- 12:11Evented Ruby
- 13:12Ruby Reactors
- 13:53Add a Reactor
- 14:13Add Events
- 15:28Procedural Interface, Evented Execution
- 17:37Code Smell?
- 18:23Rack::FiberPool
- 18:47Recap
- 19:05Mixing Paradigms
- 19:50Starting points
- 20:05Data Stores
- 20:26System Calls
- 20:51Final Result
- 21:03Why Ruby
- 21:39Why Node
- 22:12Have cake and eat it too
- 23:01Example
- 23:49Wrapping Up
