1) Node.JS is not single threaded. It uses multiple threads. But the JavaScript virtual machine (V8 in most of the cases) is single threaded (in a way, there are ways to make threads and processes). So any call served by JavaScript is mostly single threaded. However, you could create threads, processes and workers under node.js if you like to introduce parallelism in addition to the async programming Node.JS naturally provides
2) I am not quite sure what are you trying to achieve here. If the question is, "could I write my whole code into a single file?", yes you could. If the question is, "is the require loads all the code into a single app and then executes it?", this is not quite right. CommonJS does that, but in Node.JS it is bind to a bit lower level. The CommonJS behavior is emulated, but the performance is a bit higher. Keep in mind, each module runs within its own scope, as well as it is cached (so it is loaded just once, even if you refer to it from multiple locations). Even the main loaded app is actually treated as module and runs within its own scope isolated from the rest. Very little things are present in the Node's "global" scope
3) Look at my answer for question 2. Each module, including your main app starting point are running within different scope. None of them has access to the global "global" scope. There is a such thing, but not made for easy access. Look at this example:
a.js:
globalVar = 1
global.myGlobal = 33
require('./b')
b.js:
console.log(global, global.globalVar, global.myGlobal);
console.log(globalVar)
If there was a global space the way you think it is, if you run node ./a.js you shall get as output the value of globalVar and myGlobal. But you won't.
Because each module has it's own global.
However, because of the caching (a module is loaded only once), if you need to have a global variable that is accessible from multiple modules and locations, you could do it with a module.
See this example:
a.js:
var b = require('./b');
console.log(b.sharedVariable++);
require('./c');
b.js:
sharedVariable=33;
module.exports = global
c.js:
var b = require('./b');
console.log(b.sharedVariable);
If you run this with node ./a.js you will get 33 and 34. Which is only possible, if the b module is loaded only once internally, and all the other calls just get reference to it. If that was not true, you would have get 33 and 33. This is a good thing. It not only speeds node, the compilation and the loading process, but is also giving you a mechanism to create internal messaging if needed, trough a specially designed module. Anyway, do not implement your modules as with this example. The example is there to prove a point (localized global namespace and caching). There are better patterns for writing modules :)
4) Single connection in what sense? Node does not use single connection, nor provides such. You have a quite good control into your sessions, you can open many connections or reuse the same if you like, or use pools. You can do whatever you like.
5) Do not write synchronous code. Split it into as much smaller tasks as possible and this will keep the execution jitter of your app smaller.
6) I am not having the feeling that Angular is compared to Express. Express is just a popular HTTP path router used in Node.JS (and it is not the only one), while AngularJS is (mostly) a front end UI running at the browser. They work together, not against each other. Even if you use Angular Universal (server side Angular, that pre-compiles part of the Angular code before loading it to the browser) you may still need http router as express at your backend in order to serve your REST queries. They are really different things
