Building Backend Services for Frontend Teams
express, hapi, and koa are web frameworks built on top of the Node.js runtime, designed to simplify server creation, routing, and middleware management. express is the most widely adopted standard, offering a minimalist approach to building APIs and web servers. hapi focuses on configuration-driven development with a strong emphasis on security and plugin architecture. koa was created by the original team behind express to leverage modern JavaScript features like async/await without callback hell. node refers to the Node.js runtime itself; while there is an npm package named node, professional server development relies on the runtime's native http modules rather than installing a package with that name.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Express vs Hapi vs Koa vs Node: Architecture and DX Compared
When frontend architects step into backend development, choosing the right server foundation is critical. express, hapi, and koa are frameworks that run on the Node.js runtime, while node itself represents the underlying platform. Each handles requests, middleware, and errors differently. Let's compare how they tackle common server-side problems.
🏗️ Core Architecture: Request Handling Models
express uses a request-response model where req and res are separate objects passed to handlers.
- Middleware functions have access to both objects directly.
- Simple to understand for developers coming from other web backgrounds.
// express: Separate req and res
app.get('/user', (req, res) => {
res.json({ id: 1 });
});
hapi relies on a configuration-first approach where routes are defined with detailed options.
- Handlers receive a
requestobject and must return a response explicitly. - Enforces strict input validation and structure.
// hapi: Configuration object
server.route({
method: 'GET',
path: '/user',
handler: (request, h) => {
return { id: 1 };
}
});
koa uses a single ctx (context) object that combines request and response.
- Middleware functions await the next step in the chain.
- Eliminates the need to pass multiple arguments around.
// koa: Single context object
app.use(async (ctx) => {
ctx.body = { id: 1 };
});
node (Native) requires using the raw http module without abstractions.
- You must manually parse URLs and headers.
- Highest performance potential but highest code complexity.
// node: Native http module
const http = require('http');
http.createServer((req, res) => {
res.end(JSON.stringify({ id: 1 }));
}).listen(3000);
🥞 Middleware Flow: Linear vs Encapsulated
express middleware runs in a linear stack.
- You call
next()to pass control to the next function. - Easy to add logging or auth checks globally.
// express: Linear middleware
app.use((req, res, next) => {
console.log('Time:', Date.now());
next();
});
hapi uses extensions and plugins rather than simple middleware functions.
- Logic is attached to specific lifecycle events (onRequest, onPreHandler).
- Better for isolating features in large teams.
// hapi: Lifecycle extension
server.ext('onRequest', (request, h) => {
console.log('Time:', Date.now());
return h.continue;
});
koa middleware wraps around the downstream logic using async/await.
- You can run code before and after the response is generated.
- Provides cleaner error handling flows.
// koa: Wrapped middleware
app.use(async (ctx, next) => {
console.log('Start');
await next();
console.log('End');
});
node has no built-in middleware system.
- You must manually chain functions or build your own dispatcher.
- Requires significant boilerplate to replicate framework features.
// node: Manual chaining
function middleware(req, res, next) {
console.log('Time:', Date.now());
next(req, res);
}
⚠️ Error Handling: Centralized vs Distributed
express uses a special error-handling middleware signature.
- Errors passed to
next(err)skip to the error handler. - Simple but requires remembering the four-argument function shape.
// express: Error middleware
app.use((err, req, res, next) => {
res.status(500).send('Error');
});
hapi handles errors via response objects or throwing errors in handlers.
- Built-in support for error formatting and logging.
- Consistent structure across all routes.
// hapi: Throw error
handler: (request, h) => {
throw new Error('Something failed');
}
koa leverages standard try/catch blocks due to async functions.
- No special error middleware signature needed.
- Feels more natural to JavaScript developers.
// koa: Try/Catch
app.use(async (ctx, next) => {
try {
await next();
} catch (err) {
ctx.status = 500;
}
});
node requires manual try/catch in every async operation.
- Uncaught errors can crash the entire process.
- High risk of missing edge cases without careful coding.
// node: Manual error handling
try {
// logic
} catch (err) {
res.statusCode = 500;
res.end();
}
📦 Package Status and Maintenance
It is critical to note the maintenance status of these tools before committing.
express: The standard choice. Version 5 was recently released to modernize the codebase. Long-term support is reliable.hapi: Actively maintained. It shifted licenses in the past but is now stable under a BSD license. Strong enterprise adoption.koa: Maintained by the Express team. Smaller ecosystem but very stable. No major breaking changes recently.node: The npm package namednodeis a polyfill for browser usage, NOT the server runtime. For servers, you install the Node.js runtime directly. Do notnpm install nodefor backend development.
🤝 Similarities: Shared Ground Between Frameworks
While the differences are clear, all three frameworks share core concepts built on the Node.js runtime.
1. 🌐 Built on Node.js Runtime
- All rely on the V8 engine and libuv for async I/O.
- Share the same event loop mechanics.
// All use non-blocking I/O
setTimeout(() => console.log('done'), 0);
2. 🔌 Extensible via Middleware/Plugins
- All allow adding logging, auth, and parsing via extensions.
- Ecosystems provide ready-made solutions for common tasks.
// express: body-parser
app.use(express.json());
// koa: koa-bodyparser
app.use(bodyParser());
3. 🚀 HTTP Server Capabilities
- All can handle REST, GraphQL, and WebSocket upgrades.
- Support standard HTTP methods and status codes.
// All support standard methods
app.get('/', handler);
app.post('/', handler);
📊 Summary: Key Differences
| Feature | express | hapi | koa | node (Native) |
|---|---|---|---|---|
| Style | Minimalist | Configuration | Modern Async | Raw Implementation |
| Context | req + res | request + h | ctx | req + res |
| Middleware | Linear Stack | Lifecycle Events | Wrapped Async | Manual |
| Error Handling | Special Middleware | Throw/Response | Try/Catch | Manual Try/Catch |
| Learning Curve | Low | High | Medium | Very High |
💡 The Big Picture
express is the reliable workhorse 🐴 — best for teams that want to ship fast with maximum community support. Ideal for startups, MVPs, and standard APIs.
hapi is the structured enterprise kit 🏢 — perfect for large teams needing strict validation and plugin isolation. Shines in complex, regulated environments.
koa is the modern developer tool 🛠️ — great for those who want clean async code without legacy callback patterns. Best for microservices and modern stacks.
node (Native) is the engine block 🚗 — use only when you need to build the car from scratch. For 99% of web tasks, a framework saves time and reduces bugs.
Final Thought: For most frontend teams building backend-for-frontend layers, express offers the smoothest transition. If you value code cleanliness and modern syntax, koa is a strong alternative. Avoid raw node unless you have a specific performance constraint that frameworks cannot meet.
How to Choose: express vs hapi vs koa vs node
- express:
Choose
expressif you want the industry standard with the largest ecosystem of plugins and tutorials. It is ideal for teams that need quick setup, extensive community support, and a straightforward request-response model. This is the safest bet for most general-purpose APIs and server-side rendering setups. - hapi:
Choose
hapiif you prefer a configuration-heavy approach that enforces structure and security out of the box. It is suitable for large enterprise applications where input validation and plugin isolation are critical. The learning curve is steeper, but it reduces boilerplate for complex validation rules. - koa:
Choose
koaif you want a modern codebase built on async/await without the baggage of older callback patterns. It is best for teams that value clean middleware composition and want full control over the response context. It works well for microservices where lightweight performance is key. - node:
Choose raw
node(native http module) only if you need maximum control over every byte sent over the network or are building a custom protocol. For standard web APIs, this is rarely recommended due to the high boilerplate cost. Use this only for specialized tools or when framework overhead is strictly prohibited.
Popular Comparisons
README for express
Fast, unopinionated, minimalist web framework for Node.js.
This project has a Code of Conduct.
Table of contents
- Table of contents
- Installation
- Features
- Docs & Community
- Quick Start
- Philosophy
- Examples
- Contributing
- Current project team members
- License
import express from 'express'
const app = express()
app.get('/', (req, res) => {
res.send('Hello World')
})
app.listen(3000, () => {
console.log('Server is running on http://localhost:3000')
})
Installation
This is a Node.js module available through the npm registry.
Before installing, download and install Node.js. Node.js 18 or higher is required.
If this is a brand new project, make sure to create a package.json first with
the npm init command.
Installation is done using the
npm install command:
npm install express
Follow our installing guide for more information.
Features
- Robust routing
- Focus on high performance
- Super-high test coverage
- HTTP helpers (redirection, caching, etc)
- View system supporting 14+ template engines
- Content negotiation
- Executable for generating applications quickly
Docs & Community
- Website and Documentation - [website repo]
- GitHub Organization for Official Middleware & Modules
- Github Discussions for discussion on the development and usage of Express
PROTIP Be sure to read the migration guide to v5
Quick Start
The quickest way to get started with express is to utilize the executable express(1) to generate an application as shown below:
Install the executable. The executable's major version will match Express's:
npm install -g express-generator@4
Create the app:
express /tmp/foo && cd /tmp/foo
Install dependencies:
npm install
Start the server:
npm start
View the website at: http://localhost:3000
Philosophy
The Express philosophy is to provide small, robust tooling for HTTP servers, making it a great solution for single page applications, websites, hybrids, or public HTTP APIs.
Express does not force you to use any specific ORM or template engine. With support for over 14 template engines via @ladjs/consolidate, you can quickly craft your perfect framework.
Examples
To view the examples, clone the Express repository:
git clone https://github.com/expressjs/express.git --depth 1 && cd express
Then install the dependencies:
npm install
Then run whichever example you want:
node examples/content-negotiation
Contributing
The Express.js project welcomes all constructive contributions. Contributions take many forms, from code for bug fixes and enhancements, to additions and fixes to documentation, additional tests, triaging incoming pull requests and issues, and more!
See the Contributing Guide for more technical details on contributing.
Security Issues
If you discover a security vulnerability in Express, please see Security Policies and Procedures.
Running Tests
To run the test suite, first install the dependencies:
npm install
Then run npm test:
npm test
Current project team members
For information about the governance of the express.js project, see GOVERNANCE.md.
The original author of Express is TJ Holowaychuk
TC (Technical Committee)
- UlisesGascon - Ulises Gascón (he/him)
- jonchurch - Jon Church
- wesleytodd - Wes Todd
- LinusU - Linus Unnebäck
- blakeembrey - Blake Embrey
- sheplu - Jean Burellier
- crandmck - Rand McKinney
- ctcpip - Chris de Almeida
TC emeriti members
TC emeriti members
- dougwilson - Douglas Wilson
- hacksparrow - Hage Yaapa
- jonathanong - jongleberry
- niftylettuce - niftylettuce
- troygoode - Troy Goode
Triagers
- aravindvnair99 - Aravind Nair
- bjohansebas - Sebastian Beltran
- carpasse - Carlos Serrano
- CBID2 - Christine Belzie
- UlisesGascon - Ulises Gascón (he/him)
- IamLizu - S M Mahmudul Hasan (he/him)
- Phillip9587 - Phillip Barta
- efekrskl - Efe Karasakal
Triagers emeriti members
Emeritus Triagers
- AuggieH - Auggie Hudak
- G-Rath - Gareth Jones
- MohammadXroid - Mohammad Ayashi
- NawafSwe - Nawaf Alsharqi
- NotMoni - Moni
- VigneshMurugan - Vignesh Murugan
- davidmashe - David Ashe
- digitaIfabric - David
- e-l-i-s-e - Elise Bonner
- fed135 - Frederic Charette
- firmanJS - Firman Abdul Hakim
- getspooky - Yasser Ameur
- ghinks - Glenn
- ghousemohamed - Ghouse Mohamed
- gireeshpunathil - Gireesh Punathil
- jake32321 - Jake Reed
- jonchurch - Jon Church
- lekanikotun - Troy Goode
- marsonya - Lekan Ikotun
- mastermatt - Matt R. Wilson
- maxakuru - Max Edell
- mlrawlings - Michael Rawlings
- rodion-arr - Rodion Abdurakhimov
- sheplu - Jean Burellier
- tarunyadav1 - Tarun yadav
- tunniclm - Mike Tunnicliffe
- enyoghasim - David Enyoghasim
- 0ss - Salah
- import-brain - Eric Cheng (he/him)
- dakshkhetan - Daksh Khetan (he/him)
- lucasraziel - Lucas Soares Do Rego
- mertcanaltin - Mert Can Altin
- dpopp07 - Dustin Popp
- Sushmeet - Sushmeet Sunger
- 3imed-jaberi - Imed Jaberi