Stream Whack a Mole
summary
Describes concrete bugs, fixes and tools: confusing semantics around end/finish/data that cause memory leaks and race conditions, the runtime recommendation to always drain streams (resume or pipe) and to depend on readable-stream for consistent behavior, and a tested utility end-of-stream (used by ~1.6M repos) plus safer piping via pump/pipeline. Presents a new implementation, streamx, aimed at simpler lifecycle hooks (open/destroy) and good backwards compatibility, and reports it works in internal projects.
AI-written summary · about
chapters (22)
- 0:00Intro
- 0:20P2P Node.js Core Streams
- 1:14A depressing story on why you probably all have bugs in your streams
- 1:35A Brief History of Node.js Streams
- 1:46Streams 1
- 3:12Streams 2 - Node.js 0.10
- 4:15Complex Batteries included Pull based
- 4:36Streams 3 - Node.js ~0.11
- 4:48Makes the s.on('data') work together with the
- 5:09Streams are still evolving
- 5:28Everytime we fix a bug we break tons of things
- 5:47Streams are probably the most complex objects returned from Node.js core
- 7:16readable-stream is an official npm mirror of stream(node)
- 8:54Memory leak. Always drain your streams node
- 10:01Yes, on('data') has magic behaivor
- 10:36does not mean end
- 14:29Backwards compat
- 17:16pipe() does not do error handling
- 18:07Never use pipe()
- 24:00The Future
- 25:11Makes streams easier to implement de
- 27:18Thank you!
related talks
28mThe good, the bad and the ugly of nodejs streams
44mThirst-Quenching Streams for the Reactive Mind
31mHydro: A Stack for Faster Streaming Applications
34mStream into the Future
30mNode.js Deep Debugging
24mDemystifying Memory Leaks in JavaScript
01h 31mReactive Streams / Akka Streams
24mAsync and Streaming JS - Are we doing it wrong?