The event loop and thread sturvation
Just like in browser environment, at the heart of handling events on the server is the Event Loop, which runs in the background checking for events and executing javascript functions that are assigned to that event.
This also brings up the issue of thread starvation, known in browser also as blocking UI, which happens when there are no CPU resources left for handling additional operations.
Thread starvations happens because of heavy, long lasting operations which block the OS from assigning new threads or in nodes example blocking the single thread from reaching other tasks on the queue.
You could say that node is the wrong choice for heavy server operations, but when taking in consideration the above the same issue will be encountered on other servers as well.
The thing is, heavy lifting operation should be off-loaded to offline execution or handling of Databases in the first place.
The file system
Node.js uses the CommonJS module loading system.
In CommonJS every file stands as a module on its own, and has a module object defined for it (in the scope of its execution), which can be accessed only buy the defining file. The module object has an exports object defined on it, which provides the API object of the file module.
When other files use the globally defined require() function, by providing it a path to file, the script is executed and only the module.exports object is defined.
This is desired since the module.exports also acts as a sort of a name-space, importing modules safely without name collisions.
NOTE! an import statement should provide a path that is relative, and without the .js mime type. This is done for consistency reasons between server and client, where the client does not know what file types the server is using (c#/Typescript/Js).