Node.js Foundation User Feedback Meeting 2018-05-11 - General team - working session

[mhdawson]

Time

UTC Fri 11-May-2018 16:00 (04:00 PM):

Timezone	Date/Time
US / Pacific	Fri 11-May-2018 09:00 (09:00 AM)
US / Mountain	Fri 11-May-2018 10:00 (10:00 AM)
US / Central	Fri 11-May-2018 11:00 (11:00 AM)
US / Eastern	Fri 11-May-2018 12:00 (12:00 PM)
London	Fri 11-May-2018 17:00 (05:00 PM)
Amsterdam	Fri 11-May-2018 18:00 (06:00 PM)
Moscow	Fri 11-May-2018 19:00 (07:00 PM)
Chennai	Fri 11-May-2018 21:30 (09:30 PM)
Hangzhou	Sat 12-May-2018 00:00 (12:00 AM)
Tokyo	Sat 12-May-2018 01:00 (01:00 AM)
Sydney	Sat 12-May-2018 02:00 (02:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+User%20Feedback+Meeting+2018-05-11&iso=20180511T16
• or http://www.wolframalpha.com/input/?i=04PM+UTC%2C+May+11%2C+2018+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1kswsnzh5ziblp3mcrKS8S3_UPGo7EK5MLybIoDCqxDM/edit

Agenda

Working session with General user feedback group.

• Next steps
• Top priority action items

Invited

• Userfeedback Members: @nodejs/user-feedback + members of the general feedback group (through email) and others who want to participate.

Observers

Notes

The agenda comes from issues labelled with user-feedback-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/353642832
• For those who just want to watch: https://www.youtube.com/channel/UCQPYJluYC_sn_Qz_XE-YbTQ/live

[aaronbartell]

@mhdawson I can make it and it's in my calendar. Looking forward to it!

Potential Agenda Topics

I help IBM i shops adopt Node.js. Node.js has been on the platform since 2015 timeframe and has recently seen a surge of in interest. Below are some of the questions I get asked on a regular basis based on my customers finding non-favorable information about Node.js in articles. I am hoping we can refine the answers to be correct and add adequate references where needed.

Threading

Issue: Since Node.js has a single-thread JavaScript event loop, when it executes long-running or high computational intensive tasks (which is quite common in enterprise applications), it queues all the incoming requests to wait for execution. This will result in poor performance. Also, it doesn’t scale out to take advantage of the multiple cores commonly present in today’s server-class hardware. So, the execution of Node.js on server-class hardware results in heavy utilization of one CPU core while leaving the other CPU cores underutilized... hence, the solution is not scalable enough. Alternatively, to scale out you need to offload such CPU intensive tasks to other Node.js servers (node cluster) which is not always advisable as it requires additional hardware and maintenance difficulties. So, for typical enterprise applications (e.g. batch processing) where you need multi-threaded execution with controlled and cohesive inter-thread communication, Node is not suitable.

Answer: It's true that Node.js has a single main thread where it runs Javascript. Things relating to I/O (disk, network, DB) are handled in separate threads and those threads do not block the main thread. Node.js also has built-in clustering capabilities so you can easily use multiple CPUs. These capabilities can be implemented with a couple lines of code.

More information here: Don't Block The Event Loop

Callback hell

Issue: Also, everything is asynchronous—which hurts. Coding consists of callbacks within callbacks within callbacks… it’s a Callback hell—pretty messy code, very difficult to understand and maintain. There are ways for having better code and managing callback hell, but then we are relying too much on having good practices and disciplined programmers.

Answer: The introduction of async/await remedied this issue by making coding feel "top down", though still doesn't block the main event loop. You can see an example here.

Server Isolation

Issue: Node developers generally initialize webserver and run business code in the same process—there is no isolation between the application server and business process which other mature servers like Tomcat or Apache HTTP servers provide. Also, not having any isolation leads the server to crash if business code throws some exception.

Answer: Use pm2 (process manager) in the event a server crashes because of uncaught exceptions.

Weak Typing

Issue: The weak type nature of JavaScript and Node.js makes it easy to leak defects, no compilation phase, and no type checking meaning that code is lot more prone to bad references or null pointer exceptions which are discovered at runtime. Especially with large enterprise applications having larger code and multiple developers working on the same code base, the missing types are more a problem for productivity than an advantage. Actually, in weak typed languages, the programming discipline must be even stricter than in strongly typed ones.

Answer: This is why many are adopting Typescript, including the likes of Angular which use it exclusively. The adoption of Typescript also provides additional tooling in dev environments like VS Code.

Npm

Issue: The way npm is structured also makes it quite difficult to find trustable packages. As it is open to all, anyone can publish their own modules making it harder to spot reliable, stable, and mature packages. Not being backed by a standard body, using NPM packages is still a risky game. Here is an interesting article on how one developer broke Node.

Answer: Package selection is no different than any other language. Don't forsake researching before adopting. With that said, the Node community has learned some lessons the hard way, as was mentioned in the link.

IDE/Debugging

Issue: There are a few other limitations which will prevent Node.js from being a choice enterprise application technology stack. There's no support for distributed transactions, limited debugging & IDE support (StrongLoop debugger works only in a couple of browsers), a lack of standard and matured libraries, and a lack of a good IDE which seriously impacts development. According to my experience, explicitly typed languages are more readable, generate robust code, and have good IDE + testing tool support.

Answer: VSCode is a strong development environment that includes a step debugger. Also, there is excellent server-side Node.js debugging in Chrome.

Security

Issue: While Node is working on a security project—and security is a top priority—it isn't rock solid against attacks. And, the availability of the Node application is questionable which makes Node application for a few sectors like financial services, banking, and investment worrisome.

Answer: Need more info on what specific security things are being discussed. Most all open source has security vulnerabilities (i.e. OpenSSL).

[matvi3nko]

I definitely want to participate in the discussion. Last time I'm interested in the decomposition of the main thread, with the transfer of CPU bound tasks, APM agents, logging, and other logic with blocking execution to individual processes. I did measurements and got good results.
@mhdawson Thanks for the invitation again!

[aheckmann]

I can make this one.

[bnb]

I should be able to make this 👍

I won't be able to attend this one, due to my travelling in Europe, I’ll be on the plane at that time, returning to US. I’ll watch the recording afterwards on Youtube and then handle the md-meeting notes.

[mcollina]

The above information is not completely correct

Answer: It's true that Node.js has a single main thread where it runs Javascript. Things relating to I/O (disk, network, DB) are handled in separate threads and those threads do not block the main thread. Node.js also has built-in clustering capabilities so you can easily use multiple CPUs. These capabilities can be implemented with a couple lines of code.

most of fs is executed in a Thread Pool. However all network operations are executed in fully asynchronous way through kernel primitives (epoll, kqueue, IOCP, event ports, etc).
A better phrasing is "..handled via kernel primitives (epoll, kqueue, IOCP, event ports) or through a Thread Pool, so that those operations do not block the main thread".

Answer: The introduction of async/await remedied this issue by making coding feel "top down", though still doesn't block the main event loop. You can see an example here.

This is misleading. It's completely possible to write callback code without "callback hell", and it's possible to write promise code with "callback" hell. It's a lengthy subject that is very hard to simplify with a single sentence.

Answer: Use pm2 (process manager) in the event a server crashes because of uncaught exceptions.

Node.js is built for Cloud Native applications. I would recommend to use Docker, Kubernetes instead to manage this. It's ok to let things crash.

VSCode is a strong development environment that includes a step debugger. Also, there is excellent server-side Node.js debugging in Chrome.

I would recommend node --inspect first, and VSCode second.

Answer: Need more info on what specific security things are being discussed. Most all open source has security vulnerabilities (i.e. OpenSSL).

You can find the 3rd-party triage process from the security wg here (https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md).
The overall point should be "KEEP YOUR DEPENDENCIES UP TO DATE AND USE A SCANNING TOOL".

[aaronbartell]

@mcollina Thank you for your responses.

It's completely possible to write callback code without "callback hell", and it's possible to write promise code with "callback" hell. It's a lengthy subject that is very hard to simplify with a single sentence.

Do you have a favorite resource you like to point people at that adequately addresses the topic? There's always callbackhell.com but it doesn't digress into the more recent async/await.

Node.js is built for Cloud Native applications. I would recommend to use Docker, Kubernetes instead to manage this. It's ok to let things crash.

On the IBM i platform (f.k.a. AS/400) we are limited to chroot environments for containerization :-( They work "good enough" for most purposes. We don't have go-lang on IBM i(yet) so Docker/Kubernetes is currently out of the question.

[ahmadnassri]

I really wish I could make this meeting, and provide some counter enterprise context to the topics mentioned in the article @aaronbartell linked. but sadly I will be traveling.

I would add that the community would benefit from having strong articles in recognized publications (such as DZone!) and especially Enterprise-friendly publications (e.g. Forbes, FastCompany, etc ...) print and online rather than Medium posts (which we have plenty of, but are not frequented by the Enterprise target demographics @aaronbartell mentions)

This is very simply achievable! with strong content writers, and name-brand enterprise companies backing the article(s) you can get equal -if not bigger- exposure to future clients and users alike.

I'd be first to volunteer myself and my company's name to contribute here, I'm sure companies like IBM and NearForm have strong use-cases / whitepappers to share content & examples.

[bnb]

Join link: https://zoom.us/j/353642832

[aaronbartell]

Where would be the best place for me to log future "community questions" topics?

In a previous User Feedback meeting @dshaw made a good observation that topics have been thoroughly debated in the past by Node.js early-adopters, though now there is a next round of Node.js adopters and they have the same questions.

The challenge with the next Node.js adopters is wading through all the opinions on Medium and StackOverflow.

One Idea

My hope is that we can curate questions in the user feedback meetings and then eventually have the question and answer be posted on nodejs.org (maybe the Guides area).

An example of a recent question is "Can the included Node.js web server be used in production?" The question is being asked because of past experiences of RubyOnRails including a non-production-ready webserver, Webrick; or PHP requiring Apache/Nginx. The answer, in my mind, is "it depends". For example, if you're not serving up static content and have a single server (n1)then using either Node.js Cluster or pm2 to load balance could very well be "good enough".

n1 - Having a single server might seem foolish, but when we get into "big iron" (i.e. IBM i), many companies have thrived with a single server for decades. The hardware/OS/DB is rock solid. I digress on this point because what might have been true for Linux/Windows Node.js workloads might not be true for IBM i/AIX/etc.

Another option

Maybe ask the questions in this repo and have core committers or prominent Node.js community members weigh in.

[mhdawson]

@aaronbartell I think we can put together an FAQ and once we think it is ready for broader review open a PR to add it to the nodejs.org website. At that point we'd want to solicit broad input to make sure there is consensus on the answers.