More Related Content
What's hot (20)
Similar to Using Node.js to Build for the Enterprise (20)
More from Microsoft Tech Community (20)
Recently uploaded (20)
Using Node.js to Build for the Enterprise
- 3. James M Snell Open Source Architect Node.js Technical Steering Committee @jasnell
- 4. Table of content The Node.js ecosystem serves an ecosystem of millions of developers and users. The project has developed specific processes to support the needs of Enterprise developers. Usability Reliability Predictability Security Maintainability Strategic Initiatives 01 02 03 04 05 06 Source: npm rolling downloads Laurie Voss, npm COO https://twitter.com/seldo/status/988477780441481217
- 5. Usability At the heart of Node.js’ success is its fundamental ease-of-use and focus on simplicity. It’s just JavaScript. JavaScript has maintained position as the #1 programming language for open source development. Source: https://octoverse.github.com/
- 6. Reliability The week Node.js 10.0.0 was released, we hit 1+ million downloads per day.
- 7. Reliability The development practices that have been built around Node.js Core are specifically designed to prioritize the reliability of the platform. ● Node.js core has had 22,000+ commits from nearly 2000 individual contributors ● So far in 2018, there have been 1700+ pull requests ● There are 118 individuals with commit access to the main repository ● There are 137 repositories in the Node.js GitHub organization ● As of right now, there are 4 supported major release lines (6.x, 8.x, 9.x, and 10.x)
- 8. Reliability
- 9. Reliability To ensure Node.js’ reliability, a comprehensive continuous integration and testing environment been worked into everything we do. ● Every code change must pass linting and testing. ● Tests run on up to 45 different operating system and architecture combinations. ● 2200+ individual test cases. ● Changes to docs must pass linting also.
- 10. Reliability Understanding the impact of our work on the ecosystem, and on the individuals who support that ecosystem is vital. ● We proactively test about 100 of the most depended upon modules for every potentially breaking change. ● 16 different operating system and architecture combinations. ● Identify issues early and fix things on our end or help userland fix things on theirs.
- 11. Reliability Issues do arise. Regressions happen. We support the ecosystem best not by avoiding issues (which is impossible), but by recovering from them quickly. ● We will revert breaking changes quickly if userland is broken in unexpected, or intolerable, ways. ● We actively seek the input of those who may be most affected by any given change. ● We proactively open pull requests on userland projects to fix issues in advance of a release. It is our responsibility to avoid changes in core that unreasonably break your code.
- 12. Predictability A key component of ensuring the reliability of Node.js releases is ensuring the predictability of releases. ● Node.js follows the Semantic Versioning conventions. ● Semver-Major: Any change that may potentially break existing code. ● Semver-Minor: Any additive change. ● Semver-Patch: Bug-fixes X . Y . ZBreaking changes to defined behaviour that may require code changes in userland. New capabilities that should never be breaking. Bug fixes and non- additive, non-breaking changes
- 13. Predictability There is a formal process for handling experimental new capabilities and for deprecating and removing functionality that userland should no longer rely upon. ● Experimental: Capabilities and APIs that are not yet officially supported and may change at any time independent of typical semver rules. ● Documentation-only Deprecation: Clear statements added to documentation explaining that a capability or API should no longer be used, but there is no change in behaviour at runtime. ● Runtime Deprecation: Intentionally disruptive warning statement is emitted to the console the first time a deprecated capability or API is used. ● End-of-life: Capabilities and APIs that are no longer supported in any way and may be removed outside of typical semver rules
- 14. Predictability One of the more critical lessons that the Node.js project had to learn is that regular predictable releases are of critical importance to its success in the enterprise. ● Major releases every 6 months ● April: Even-numbered majors (e.g. 4.0.0, 6.0.0, 8.0.0, 10.0.0) ● October: Odd-numbered majors (e.g. 5.0.0, 7.0.0, 9.0.0, 11.0.0) ● Odd-numbered majors are only supported for a maximum of 9 months.* ● Even-numbered majors move under Long-Term Support after 6 months. ● Active: 18 months of proactive support. ● Maintenance: 12 months of reactive support. * This does not mean odd-numbered majors are experimental! They are just as stable as even-numbered, just not supported as long.
- 15. Predictability
- 17. Security Responsible and professional handling of security vulnerabilities is critical. ● Security reporting using [email protected] and managed via HackerOne ● Triage of reported vulnerabilities for core and the ecosystem is limited to a subset of Node.js collaborators who maintain strict confidentiality ● The Node.js Project manages the Node.js Ecosystem Vulnerability Database ● The Node.js Project acts as its own CVE Authority ● There is now a Security Vulnerability Bug Bounty Program with cash awards sponsored by the Node.js Foundation and The Internet Bug Bounty program (https://internetbugbounty.org/).
- 18. Maintainability It is simply not enough to easily write code with Node.js, that code needs to be maintainable, observable, and debuggable. Of all the strategic initiatives within Node.js core, the most critical is the effort to improve diagnostics.
- 19. Maintainability ● Improved tracing, error handling, post-mortem debugging, diagnostics, performance profiling, monitoring, and auditability. ● Active development efforts around V8 Trace Events, DTrace, eBPF, node-report, node-heapdump, llnode ● Development on third party open source tools such as clinic (problem determination), 0x (profiling) and partnerships with commercial application process monitoring providers ● Experimental efforts around new debugging models such as Microsoft’s Time Travel Debugging via node- chakracore
- 20. Strategic Initiatives There is no official roadmap and no centralized project management. We do, however, have a number of strategic initiatives... ● Improved diagnostics and observability ● Improved and expanded standards support (HTTP/2, URL, TLS 1.3) ● Support for modern JavaScript language features (Modules, Promises) ● Multi-threading and multi-process support via Workers ● Improvement of Error messaging and handling ● Improvements to data processing and throughput (Streams API) ● Collaboration with key dependencies (V8, Chakra-Core, npm) ● Establishment of a Mentorship Program