aaronbartell
commented
6 years ago @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
aheckmann
bnb
ghost
mcollina
ahmadnassri
mhdawson
Time
UTC Fri 11-May-2018 16:00 (04:00 PM):
Or in your local time:
Links
Agenda
Working session with General user feedback group.
Invited
Observers
Notes
The agenda comes from issues labelled with
user-feedback-agendaacross 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