Search This Blog

Thursday, 25 October 2018

Why Node.js® - several reasons of nodejs popularity?

Node.js®, known as Node is gaining attention of designer. Node has been proved as good option to write highly scalable network solutions. We recently choose Nodejs as our server language.

Asynchronous event driven JavaScript runtime 

Node is designed to build scalable network applications. Using nodejs many concurrent connection can be handle. On each connection the callback is fired, but if there is no work to be done, Node will sleep. This is opposite to common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use.

Node are free from worries of dead-locking the process

Users of Node are free from worries of dead-locking the process, since there are no locks. Almost no function in Node directly performs I/O, so the process never blocks.
Because nothing blocks, scalable systems are very reasonable to develop in Node.

Similarity with Ruby's Event machine and Python's twisted 

Node is similar in design and influenced by system like Ruby's Event machine and Python's twisted. Node took the event model a bit further. It presented an event loop as a runtime construct instead of as a library. In other systems there is always a blocking call to start the event-loop. This behavior is defined through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run().

In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser JavaScript — the event loop is hidden from the user

HTTP's the most important aspect of Nodejs

HTTP is a first class citizen in Node, designed with streaming and low latency in mind. This makes Node well suited for the foundation of a web library or framework.

Note - Just because Node is designed without threads, that doesn't mean one can't take
advantage of multiple core  in environment. Child processes can be spawned by using our child_process.fork() API, and are designed to be easy to communicate with. Built upon that same interface is the cluster module, which allows you to share sockets between processes
to enable load balancing over your cores. 

Monday, 3 September 2018

Fixing Typescript warning - Parameter 'param' has 'any type'

Use of noImplicitAny and suppressImplicitAnyIndexErrors inside tsconfig.json

TypeScript developers disagree about whether the noImplicitAny flag should be true or false. There is no correct answer and you can change the flag later. But your choice now can make a difference in larger projects, so it merits discussion.

When the noImplicitAny flag is false (the default), and if the compiler cannot infer the variable type based on how it's used, the compiler silently defaults the type to any. That's what is meant by implicit any.

The documentation setup sets the noImplicitAny flag to true. When the noImplicitAny flag is true and the TypeScript compiler cannot infer the type, it still generates the JavaScript files, but it also reports an error. Many seasoned developers prefer this stricter setting because type checking catches more unintentional errors at compile time.

You can set a variable's type to any even when the noImplicitAny flag is true.

When the noImplicitAny flag is true, you may get implicit index errors as well. Most developers feel that this particular error is more annoying than helpful. You can suppress them with the following additional flag:

The documentation setup sets this flag to true as well.

Android News and source code