Activity

1. mhdawson

   self-assigned this

   on May 1, 2018
2. mhdawson

   changed the title [-]Node.js Foundation User Feedback Meeting 2018-05-11[/-] [+]Node.js Foundation User Feedback Meeting 2018-05-11 - General team - working session[/+] on May 1, 2018
3. aaronbartell commented on May 1, 2018

   

   aaronbartell

   on May 1, 2018

   Contributor

   More actions

   @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).

   👍React with 👍2Reacted by LJ and Dan Shaw
4. matvi3nko commented on May 1, 2018

   

   matvi3nko

   on May 1, 2018

   More actions

   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!
5. aheckmann commented on May 1, 2018

   

   aheckmann

   on May 1, 2018

   More actions

   I can make this one.
6. bnb commented on May 1, 2018

   

   bnb

   on May 1, 2018

   Contributor

   More actions

   I should be able to make this 👍
8. mcollina commented on May 2, 2018

   

   mcollina

   on May 2, 2018

   SponsorMember

   More actions

   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".
9. aaronbartell commented on May 2, 2018

   

   aaronbartell

   on May 2, 2018

   Contributor

   More actions

   @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.
10. ahmadnassri commented on May 5, 2018

    

    ahmadnassri

    on May 5, 2018

    More actions

    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.

    👍React with 👍1Reacted by Aaron Bartell
11. bnb commented on May 11, 2018

    

    bnb

    on May 11, 2018

    Contributor

    More actions

    Join link: https://zoom.us/j/353642832
12. aaronbartell commented on Jun 5, 2018

    

    aaronbartell

    on Jun 5, 2018

    Contributor

    More actions

    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.
13. mhdawson commented on Jun 5, 2018

    

    mhdawson

    on Jun 5, 2018

    MemberAuthor

    More actions

    @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.
14. dshaw

    closed this as completedon Jul 10, 2018