We write a lot of evented code here (libevent and Ruby/EventMachine). Survival skills:
* Buffer. A tiny kernel of callback-y code buffers up data and gets an object into a simple coherent state, then a lot of synchronous code handles the action on that buffer all at once. Simplest possible example: HTTP server buffers inbound data and checks for completed request, then hands the whole request off upstream. But the pattern works at higher levels too.
* Serialize the slow path. Trade performance for maintainability by taking things that don't need to be fast and fob them off to a message queue with a sync worker on the other end.
* Functional decomposition. The temptation is that if the system gives you callbacks for events A, B, and C, that you should simply structure your code around A, B, and C. Instead, abstract away A, B, and C into interfaces. Good example: em-redis does evented Redis (and is a lifesaver), but does not handle blpop well (which is key to using Redis as a message queue). So we have a custom blpopper that just exposes a "subscribe to this key and get called back on messages" wrapper.
These may not apply to Node (I know js but not Node) but they've kept me sane through many tens of thousands of lines of C and Ruby evented socket code.
4 comments
[ 1029 ms ] story [ 1237 ms ] thread* Buffer. A tiny kernel of callback-y code buffers up data and gets an object into a simple coherent state, then a lot of synchronous code handles the action on that buffer all at once. Simplest possible example: HTTP server buffers inbound data and checks for completed request, then hands the whole request off upstream. But the pattern works at higher levels too.
* Serialize the slow path. Trade performance for maintainability by taking things that don't need to be fast and fob them off to a message queue with a sync worker on the other end.
* Functional decomposition. The temptation is that if the system gives you callbacks for events A, B, and C, that you should simply structure your code around A, B, and C. Instead, abstract away A, B, and C into interfaces. Good example: em-redis does evented Redis (and is a lifesaver), but does not handle blpop well (which is key to using Redis as a message queue). So we have a custom blpopper that just exposes a "subscribe to this key and get called back on messages" wrapper.
These may not apply to Node (I know js but not Node) but they've kept me sane through many tens of thousands of lines of C and Ruby evented socket code.