Node.js Fundamentals
What Node actually is, and the files every Node project has. Short module — but these are the warm-up questions, so the answers should come out cleanly.
What is Node.js?
A program that lets you run JavaScript outside the browser — so you can build servers, APIs and tools with it.
Before Node, JavaScript only ran inside a web page. Node took Chrome's JavaScript engine, put it in a normal program, and added the things a server needs: files, network, timers. Now the same language works on both sides.
| What Node is good at | What it's bad at |
|---|---|
| APIs that mostly wait on a database or another service | Heavy calculations, image or video processing |
| Real-time features — chat, live updates | Anything that needs real multi-threading with shared memory |
| Tools and scripts | Very large, rule-heavy domain models (C# is stronger there) |
Node.js is a JavaScript runtime built on Google's V8 engine. It lets JavaScript run outside
the browser, so you can write servers and APIs with it. It runs your code on a single thread
with an event loop and non-blocking I/O, which makes it very efficient for work that mostly
waits — database calls, API calls, file streaming — and weak for CPU-heavy work.
A runtime. This is a very common trick question, and the clean way to answer it is with the comparison to .NET:
| JavaScript world | .NET world | |
|---|---|---|
| Language | JavaScript | C# |
| Runtime | Node.js | .NET / CLR |
| Framework | Express, NestJS | ASP.NET Core |
So "I built it in Node" really means: JavaScript, running on Node, usually with Express on top.
Google's JavaScript engine, the same one inside Chrome. Its job is to take your JavaScript text and turn it into machine code the CPU can run — quickly.
| V8 does | Parsing, compiling and running JavaScript; memory and garbage collection |
| Node adds | Files, network, processes, timers — everything V8 alone can't do |
V8 is written in C++ and compiles JavaScript as it runs (JIT), which is why modern JavaScript is far faster than people expect.
Node's package manager. It's two things with one name: the command that installs libraries, and the registry (npmjs.com) they come from. It's NuGet for Node.
npm init -y # create package.json
npm install express # add a package (saved into package.json)
npm install --save-dev jest # a package only needed while developing
npm install # install everything package.json lists
npm run dev # run a script you defined
npm audit # check installed packages for known vulnerabilities
What is package.json?
The identity card of your project — its name, how to start it, and every package it needs.
{
"name": "orders-api",
"version": "1.0.0",
"main": "src/server.js",
"type": "module", // use import/export instead of require
"scripts": {
"start": "node src/server.js", // npm start
"dev": "nodemon src/server.js", // npm run dev — restarts on save
"test": "jest" // npm test
},
"dependencies": { // needed to RUN the app
"express": "^4.19.2",
"jsonwebtoken": "^9.0.2",
"mssql": "^10.0.2"
},
"devDependencies": { // needed only while developing
"nodemon": "^3.1.0",
"jest": "^29.7.0"
}
}
| Field | What it's for |
|---|---|
scripts | Named commands — the team's agreed way to start, test and build |
dependencies | Packages the running app needs |
devDependencies | Tools only developers need; left out in production |
type | "module" = ES Modules, otherwise CommonJS |
^4.19.2 allows 4.x updates (not 5.0) · ~4.19.2 allows only 4.19.x ·
4.19.2 means exactly that version. The ^ is the default and is why
two people can install the same project and get slightly different versions — which is exactly
what the lock file fixes.
| node_modules | package-lock.json | |
|---|---|---|
| What | The folder with the actual downloaded package code | A record of the exact version of every package installed |
| Size | Huge — often hundreds of MB | One file |
| Commit it? | No — put it in .gitignore | Yes, always |
| Safe to delete? | Yes — npm install rebuilds it | No |
Why the lock file matters: package.json says "Express 4.x",
which could install 4.19 today and 4.21 next month. The lock file pins exactly what worked. Use
npm ci on build servers — it installs the lock file exactly and
fails if it disagrees with package.json.
node app.js | Runs that one file directly. Fine for a quick test. |
npm start | Runs whatever you wrote under scripts.start — which might set variables, use a different entry file, or add flags. |
Use npm start in real projects: the command lives in package.json, so
everyone (and the deployment pipeline) starts the app the same way. In development,
npm run dev usually runs nodemon, which restarts the server every
time you save a file.
What does a Node project look like?
Two small decisions in there matter more than they look:
server.js separate from app.js | app.js builds the app and exports it; server.js is the only file that calls listen(). Tests can then import the app without opening a port. |
| One folder per layer | You always know where a piece of code belongs, and a new developer can find anything in seconds. |
Module 09 covers the layers in detail.npm init -y, install Express, create that folder structure, add
start and dev scripts, add a .env with a
.env.example beside it, and set up the error-handling middleware before writing
the first route.