1. IBM i Avatar IBM i
  2. opensource
  3. opensource

Wiki

Clone wiki

opensource / nodejs

View History

Table Of Contents

News

@nodejs on twitter

Learning Resources

Beginner

Intermediate

Advanced

Typescript

TypeScript Deep Dive

Business Apps

Troubleshooting

Stories

# Database - nodejs-idb-connector - Official Node.js DB2 for i adopter for IBM i. - jdbc (article) - jt400.js - sails-db2fori ##DB2 Connect Sometimes you'll want to connect to DB2 for i from another operating system (i.e. Linux). DB2 Connect uses ODBC and on IBM i that means you need to start the *DDM server, as shown below. 

STRTCPSVR SERVER(*DDM)

IBM i Specific

Version stuff

FAQ

This section has either questions or declarations made about Node.js and provides answers. Some are from this article.

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 via kernel primitives (epoll, kqueue, IOCP, event ports) or through a Thread Pool, so that those operations 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 aimed to address this and make Javascript coding feel "top down", all while not blocking the event loop. You can see an example here. With that said, 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.

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: There is excellent server-side Node.js debugging in Chrome using node --inspect. Also, VSCode is a strong development environment that includes a step debugger.

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: You can find the 3rd-party triage process from the security wg here. The overall point should be "KEEP YOUR DEPENDENCIES UP TO DATE AND USE A SCANNING TOOL".

Updated