express-typescript

express-typescript is a Node.js boilerplate that pairs Express.js with TypeScript and wires in the pieces a real server needs before it ships: clustering across CPU cores, MongoDB via Mongoose, Passport-based auth, caching, background jobs, and structured logging. It is the starting point you reach for when you want a typed Express app that already has structure, not an empty app.ts you have to grow opinions around.

It is aimed at backend engineers who are tired of re-assembling the same stack on every new service. The one-sentence reason it exists: give a new Express + TypeScript project a sane, production-shaped skeleton on day one, so you spend your time on domain logic instead of plumbing.

The problem it solves

Express gives you a router and not much else. That is the point of Express, but it means every team rebuilds the same scaffolding: where do controllers live, how are web routes separated from API routes, how does auth attach to a request, how do you run across all your cores instead of one, where do logs go and who cleans them up. Each of those is a small decision, and made ad hoc they drift into a codebase nobody wants to onboard into.

This boilerplate makes those decisions once, in a layout that reads clearly. Providers own core services (the app, the database connection, the cache, Passport). Controllers hold logic, split into web and API. Routes are declared separately for web and API with auth middleware in front. The result is a project where a new engineer can find where anything belongs without a tour.

What you get

The stack is deliberately conventional, which is the point: nothing here is exotic, so it behaves the way you expect in production. TypeScript throughout, Express as the framework, and Node’s Cluster API so the process fans out across every core on the box rather than pinning to one.

• Multi-core scaling through the Node.js Cluster API
• MongoDB integration via Mongoose models
• Authentication with Passport.js (Local, Google, and Twitter strategies), with JWT for API routes and CSRF protection for web routes
• In-memory caching with memory-cache
• Separated Web and API routes, each with auth middleware
• Background job processing with the Kue queue
• PUG templating for server-rendered views
• Custom date-based logging with automatic cleanup of old files
• Environment configuration via DotEnv
• Docker and Docker Compose support out of the box

The route layer ships with real endpoints already wired: web routes for signup, login, logout, account, Google and Twitter auth callbacks, and a status monitor, plus API routes for login, register, and refresh-token. They double as working examples of how the controller, route, and provider layers connect.

Quick look

Getting a local instance running is a clone, an install, a config edit, and one script:

# Clone repository
git clone https://github.com/GeekyAnts/express-typescript.git
cd nodets

# Install dependencies
npm install

# Configure environment
vim .env

# Run development server
npm run dev

If you would rather not manage MongoDB and Redis locally, Docker Compose brings the whole stack up:

docker-compose up        # foreground
docker-compose up -d     # background

How it works

The architecture leans on a providers pattern. On boot, provider classes stand up the core services: the Express app, the database connection, the cache, and Passport. Routes are declared in two separate configurations, one for the web (PUG-rendered pages, session and OAuth callbacks) and one for the API (token-based auth endpoints), with authentication middleware applied where it is needed rather than globally.

Scale comes from the Cluster API: instead of a single Node process, the app forks a worker per CPU core and load-balances connections across them, so a multi-core host is actually used as one. Background work that should not block a request (email, cleanup, anything slow) is pushed onto Kue queues backed by Redis. Logging is handled by a custom Log class that rotates files by date and prunes old ones on its own, so disk usage stays bounded without a cron job bolted on later.

The baseline requirements reflect that shape: Node 10.5.0 or newer, TypeScript 3.0.1 or newer, a MongoDB instance, and Redis for the queue.

For the full folder layout, the complete route table, and configuration details, see the repo.