This document provides an overview and best practices for Node.js APIs and modules. It discusses streams and buffers, using streams efficiently, buffer usage and memory management. It also covers clustering to exploit multiple CPU cores, writing reusable modules, using timers for scheduling tasks, JSON for data interchange, the NPM registry, and writing native addons in C++. The presentation emphasizes hiding complexities, avoiding global state, discrete naming, and security best practices for dependencies. It cautions against tight loops, managing stream lifecycles, and large JSON processing.

1. Node.js Learning Kit
Vipin Menon, Software Engineer, IBM
vipinmv1@in.ibm.com | @vipinmv | https://github.com/vipinmenon

2. Agenda
Introduction to Basic APIs and best practices.
Streams Buffers
Cluster Modules
Timers JSON
NPM Addons

3. stream - definition
Flowing data; perfect match for event architecture

4. stream – best practices
 Know your (data) producer, consumer and
backpressure

5. stream – best practices
 There are number of life cycle events for streams;
knowing and using those leads to efficient program
 Streams do not define data types, it flows your data as
is

6. buffer - definition
An abstraction around raw binary data

7. buffer - example

8. buffer – best practices
 Buffer is great for manipulating large in-memory data
 With `allocUnsafe()`, raw memory is exposed, so use it
with caution
 Buffer implies (large) memory, track your objects

9. cluster - definition
Share server load, exploit multiple cores

10. cluster - example
Master
Worker

11. cluster – best practices
 Use for single server multi-core exploitation; when load
grows beyond threshold, switch to horizontal scaling
 Don’t mix cluster with child_process – it adds complexity
 Session is not managed automatically, app needs to
implement one

12. modules - definition
Re-usable API abstractions

13. modules - example

14. modules – best practices
 Hide complexities under well defined APIs
 Avoid global state; avoid side effects (`process.exit`)
 Use discrete, disambiguating naming convention

15. timers - definition
Schedulers: Global APIs for future execution

16. timers - example

17. timers – best practices
 Don’t cover up program bugs with artificial delays
 `setInterval` is a recurring schedule, know when to shut
those down
 Don’t write code that critically rely on schedule precision

18. JSON - definition
 JavaScript Object Notation
 Data interchange format, native to JavaScript
 Specification for JS Object Marshalling / Unmarshalling

19. JSON - example

20. JSON – best practices
 Using a schema improves readability and speed
 Use shorter field names for serializable objects
 JSON processing is synchronous, so large (> 2 MB)
throttles the Node.js thread

21. NPM - definition
 Most popular JavaScript development tool registry
 Default Package manager for Node.js

22. npm - example

23. npm – best practices
 Known your modules! Audit and scan third party
modules periodically
 Use active and well maintained modules
 Lock your module dependencies

24. addons - definition
Foreign Function Interfacing; mainly C++

25. addons - example

26. addons – best practices
 Don’t directly deal with V8, use wrappers
 Addons run on main thread, don’t run tight loop code
 Many addon resources are not visible to Node.js so
use those under your control

27. Disclaimer
 The information contained in this presentation is provided for informational purposes only.
 While efforts were made to verify the completeness and accuracy of the information contained
in this presentation, it is provided “As Is”, without warranty of any kind, express or implied.
 In addition, this information is based on IBM’s current product plans and strategy, which are
subject to change by IBM without notice.
 IBM shall not be responsible for any damages arising out of the use of, or otherwise related to,
this presentation or any other documentation.
 Nothing contained in this presentation is intended to, or shall have the effect of:
 Creating any warranty or representation from IBM (or its affiliates or its or their supplies
and/or licensors); or
 Altering the terms and conditions of the applicable license agreement governing the use
of IBM software.

28. THANK YOU!