Node.js Anti-Patterns and bad practices
•
4 likes•4,264 views
Talk delivered at Node.js Live Paris http://live.nodejs.org/events/paris.html As Node continues to go from strength to strength, being widely adopted not only within the startup community but more and more by the Enterprise community, a number of anti-patterns are beginning to emerge. This talk focuses on the strengths of JavaScript in the Enterprise by trying to isolate the anti-patterns that are slowly beginning to emerge.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Node.js Anti-Patterns and bad practices
Similar to Node.js Anti-Patterns and bad practices (20)
Recently uploaded
Recently uploaded (20)
Node.js Anti-Patterns and bad practices
- 2. Why?
- 3. Adoption of Node.js by enterprises keep growing
- 4. Walmart, eBay, PayPal, Intuit, Netflix, LinkedIn, Uber, Yahoo ...
- 5. Java → Node.js .NET → Node.js ... → Node.js
- 6. The clash of paradigms leads to anti-patterns
- 7. Igor Principal Engineer @ YLD
- 8. YLD does Node.js consulting for large enterprises
- 9. How?
- 10. Meet Jane
- 11. Jane • Experienced Java developer in a big enterprise • Limited experience with JavaScript
- 12. Jane’s quest “create a Node.js-based prototype of an API service for a new mobile app”
- 13. Ok, let’s try this Javascript on the server thing…
- 16. Callback hell
- 24. Using a long list of arguments
- 29. Poor use of modularity
- 30. • Files with > 200 LoC • Lots of scattered functions • Low cohesion • No reuse • Testing is hard
- 31. • All the handlers for a given resource inside the same module • Modules that have loosely related functions inside it because it's the only place these functions are being used.
- 32. • modules are cheap • expose a documented interface • try to keep modules under 200 LoC
- 34. Overuse of classes for modelling
- 35. vs
- 36. …
- 37. I think I got this Node.js thing now…
- 41. The Kitchen Sink module
- 43. Synchronous execution after initialisation
- 44. • fs.readFileSync • fs.accessSync • fs.changeModSync • fs.chownSync • fs.closeSync • fs.existsSync • ...
- 46. The dangling source stream
- 47. When a stream throws an error or closes while piping, streams are not properly disposed and resources leak.
- 53. • listen for error and close events on every stream and cleanup • or use the pump package instead of the native stream.pipe()
- 58. • Setting NODE_PATH • Using a module that requires in a different way. e.g. • 'rootpath' • 'require-root' • 'app-root-path' • 'root-require'
- 61. The monolith
- 72. Testing at the wrong level
- 73. Test at the interface level All that the tests/* should require is
- 75. Depending on globally installed modules on package.son scripts
- 80. Istanbul
- 83. Poor use of public modules
- 84. • NPM is the biggest and fastest growing open source package repo • Make good use of existing open-source
- 85. • Ignorance of existing modules • NIH syndrome • Reluctance with dependency management • "My needs are unique"
- 86. “I need a testing framework that computes code coverage and sends coverage stats to coveralls.io" ¯_( )_/¯
- 87. “I need a testing framework” tap, mocha, lab “I need to compute code coverage” istanbul “I need to send coverage stats to coveralls.io" coveralls
- 88. • License • Release frequency • Last updated • Open issues • Test coverage • Documentation quality
- 92. • Parsing (response from the database, response from external service) • Computation-heavy work (like Natural Language Processing, Classification, Learning, etc.) • Processing big sequences of data • Mapping or a big dataset • Aggregating a big dataset • Calculating an HMAC for a big document
- 98. Main take-aways • Node is fundamentally different from the other technologies frequently used in big teams. • Adopting Node also means adopting its newer practices.