nodejs

This is a Node.js boilerplate that builds a full stack: a web app, a RESTful JSON API, background workers, and an interactive CLI, using nothing but Node’s built-in modules. Zero npm packages. No Express, no framework, no utility library. Just http, https, fs, zlib, readline, cluster, crypto, and the rest of the standard library doing the work you usually reach for a dependency to do.

It exists as a teaching artifact. If you have only ever built on top of Express and a node_modules folder with 800 transitive dependencies, this repo shows you the floor beneath all of that: how much a plain Node runtime already hands you for free. It is for engineers who want to understand routing, compression, TLS, clustering, and worker loops at the level where you write them yourself, not the level where you import them.

The problem it solves

Most Node tutorials teach a framework, not the platform. You learn Express routing before you have ever parsed a request URL by hand, and you learn a logging library before you have ever appended to a file and gzipped it. The abstractions are useful in production, but they hide the mechanics, and when something breaks two layers down you have no mental model for where you are.

This project removes every abstraction between you and the runtime. Every feature (serving HTTPS, routing methods, compressing responses, persisting data to disk, running background checks, spreading load across CPU cores) is implemented directly against core APIs. The result is a codebase you can read end to end and, at each point, know exactly which built-in module is responsible. It is a reference for what Node actually gives you, and a reminder of how much of the typical dependency tree is convenience rather than necessity.

What you get

The repo is a working application, not a set of isolated snippets. It runs a web app with a small template engine and static asset serving, exposes a JSON API with full CRUD for users, tokens, and checks, runs background workers that execute checks and rotate logs, and ships an interactive CLI for operating the whole thing while it runs.

• HTTP and HTTPS servers with GZIP and Deflate compression, routing GET, POST, PUT, and DELETE.
• File-backed storage under .data/ (users, checks, tokens) using fs, no database.
• Background workers that write *.log files and compress and decompress them with gzip.
• A template engine with data interpolation plus static asset serving for the web app.
• A CLI built on readline and events with commands like man, help, stats, list users, more user info --{userId}, list checks, list logs, and more log info --{fileName}.
• Clustering across available CPU cores, child-process execution, a debugger entry point, and PerformanceObserver hooks gated behind NODE_DEBUG=performance.
• A misc/ folder demonstrating async-hooks, HTTP/2, NET, UDP, TLS, REPL, and VM in isolation.

Quick look

Setup is manual on purpose: you create the data directories and generate a self-signed certificate yourself, so nothing about the runtime is hidden behind a package.

git clone https://github.com/faizahmedfarooqui/nodejs.git
cd nodejs
mkdir .data && cd .data && mkdir users checks tokens && cd ..
mkdir .logs
cd https
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem

Once the directories and certificate exist, you pick how to run it:

node index.js                        # Standard mode
node index-cluster.js                # Cluster mode
node inspect index-debug.js          # Debug mode
NODE_DEBUG=performance node index.js # Performance monitoring

Each entry point wires the same application differently: single process, one process per CPU core, or under the built-in inspector.

How it works

The three index*.js files are thin entry points; the application itself lives in lib/, which holds the server logic, the router, the request handlers, the data model, the workers, the logging layer, and the CLI. A single server module accepts both HTTP and HTTPS connections, parses the request, negotiates compression, and dispatches to a router that maps method plus path to a handler. Handlers read and write JSON files under .data/ through a small storage helper, so the persistence layer is just fs, with crypto handling password hashing (a SHA256 HMAC).

The workers run on their own interval loop, executing checks and appending results to .logs/, then compressing rotated logs with zlib. The CLI is a separate surface: it listens on readline, emits events for each recognized command, and reads the same data files the API writes, so you can inspect live state from a prompt. The https/ folder carries the certificate material and its controllers, templates/ and public/ back the web app, and misc/ keeps the more exotic core modules (HTTP/2, UDP, NET, VM, REPL, TLS, async-hooks) as standalone demos so the main path stays focused.

For the full command list, module-by-module breakdown, and the misc/ demos, see the repo.