high level node.js

What is ‘event-driven’ programming?

event-driven programming is a programming paradigm characterized by its flow being dictated — driven — by user-actions broadly defined as events. javascript hint hint wink wink nudge nudge. if you’re anything like me (god save you), you might be wondering “well wtf isn’t event-driven?”…

so event-driven programming’s arch nemesis would probably be Procedural Programming Man. Procedural Programming Man captures his user’s inputs, ties them up, and puts them in the back of a large white van. and instead of event-driven programming, now you have user-driven programming.

maybe my metaphor is ambiguous. whereas event-driven programs go where the user tells it, procedural programs just finish a set of instructions, which could be thought of as a single event; event-driven programming on the other hand, is events all the way down. did you click that? there. that was an event.
javascript: 1, procedural programming: 0

you could also just say that event-driven programs love to listen, whereas event-driven programs take but one request (but it could very well be the world’s greatest set of instructions ever recorded in binary).

What are ‘worker processes’?

worker processes are basically background processes written by a language, for a language. assuming the question means web workers, which is what javascript uses, they refer to user-defined processes that can run in a separate thread from the actual javascript runtime code. they actually exist in an entirely different “global context”. if you open your windows task manager and then click on the services tab, you’ll see some background processes. these could be thought of as worker processes for the windows os.

well, web workers are similar but on a much simpler scale (one app as opposed to a hub for hundreds or even thousands of apps on a single machine). as web developers, we’re not creating operating systems, so we naturally have less to worry about. but depending on how robust your app is (from ringtone apps to youtube) you’ll still want to process API requests, listen for user input like clicks and keystrokes, and otherwise manipulate the DOM. as app needs scale up, web workers (and sub workers, child processes of the web workers, and so on) are written as needed in order to maintain a smooth user experience (no load times, bad requests, unresponsive design, dead links, or the like).

How does Node.js handle child threads?

node.js runs your (javascript) code in a single thread, but it is written in C, C++, and javascript, while using a C library called libuv to run asynchronous I/O in the background, concurrently with your code. libuv is able to accomplish this by using a threadpool. but it is abstracted into the background, and the programmer doesn’t have to worry that much about it. the ability to write code in a single thread effectively eliminates race conditions, or conflicts of code that need to finish in a certain order or happen concurrently — without cross-talk — so that the user experience is not interrupted or caught in a loop while e.g. some HTTP-request hangs in the balance (loading spinners of doom). this helps projects to scale up continuously, and to integrate almost without limits.

newer ecmaScript features exist such as promises, async/await, and the microtasks queue which provide functionality for dividing I/O into efficient, concurrent events that scale according to user experience needs (UX) while remaining lightweight.

in short, node.js handles child threads pretty cleverly.

Describe how Node.js can be made more scalable.

because of how node.Js operates under the hood, it is possible to scale apps in a way only limited by the imagination. there are 3 main things you can do to scale your application: cloning, decomposing, and splitting.

Cloning. create multiple instances of your app and have them handle separate parts of the workload (using a load balancer for example). node.Js has a built-in module, cluster, that makes this possible using a single server. this module uses load balancing to take advantage of the host machine’s multiple CPU cores, which javascript itself ignores entirely (save for the one thread it needs).

Decomposing. this is usually described as microservices. you chop your app up into its most essential functionalities. so your search page, your shopping cart, and your forum could all be different apps, and have different codebases. microservices is a misleading term because the size of the service is not what’s important, “but rather the enforcement of loose coupling and high cohesion between services.”

Splitting. horizontal scalability. also known as sharding your database. you can split your application into multiple instances where each instance is only responsible for a portion of the data. for example, you could partition your app based on the client’s country or native language.

Explain global installation of dependencies.

by default, node installs your dependencies in your local repo, and only your local repo. alternatively, you could install them globally, where they live on your local machine in a single location and are used in any environment you happen to call them from. this is almost never recommended, since different apps often require different versions of dependencies in order to work properly. having a single, global location for that module is almost never worth the amount of space it saves (which is very little as .js is so lightweight).

however, if you always want to run a package’s (usually a devDependency’s) executable commands from the CLI (the console), and you don’t want to just use npx (which is a pretty amazing tool i just learned about… yes, i’m a newb ¯\_(ツ)_/¯), then you can add -g to the normal npm install command.
for example: npm i cowsay -g.

now you can do this whenever you want from any repository or even console you have open…