The Express Reality Check

Express.js has been the default Node.js server framework for over fifteen years. It deserves respect for what it accomplished — it made server-side JavaScript viable and introduced millions of developers to backend development. But the web has changed enormously since Express was designed, and Express has not kept up.

Here is what a "modern" Express application actually requires in 2026:

That is eleven additional packages just to get table-stakes functionality for a production server. Each with its own API, its own configuration, its own version lifecycle, and its own transitive dependencies. This is not a server framework. It is a middleware marketplace.

What forge/server Ships Out of the Box

forge/server is designed for what backend applications actually need in 2026. Everything is built-in, tested together, and configured through a single, coherent API:

import { ForgeServer } from 'hbforge/server'; const app = new ForgeServer({ port: 3000, cors: { origin: 'https://myapp.com' }, rateLimit: { window: '1m', max: 100 }, jwt: { secret: process.env.JWT_SECRET }, telemetry: { prometheus: true, tracing: true }, }); // REST routes with radix-trie matching app.get('/api/users/:id', async (ctx) => { const user = await db.find(ctx.params.id); return ctx.json(user); }); // WebSocket — RFC 6455, no external package app.ws('/live', (socket) => { socket.on('message', (data) => { socket.broadcast(data); }); }); // GraphQL — built-in engine, no Apollo app.graphql('/graphql', { typeDefs: schema, resolvers: resolvers, }); app.listen();

One import. One configuration object. No middleware installation ceremony. No compatibility matrix between eleven packages that were never designed to work together.

Radix-Trie Routing: Fast by Design

Express uses a linear array to match routes. For every incoming request, it walks through every registered route in order until it finds a match. For an application with 200 routes, that is potentially 200 string comparisons per request.

forge/server uses a radix trie (compressed prefix tree) for route matching. Lookup time is O(k) where k is the length of the URL path, regardless of how many routes are registered. For an application with 200 routes, lookup is the same speed as an application with 2 routes.

// Express: linear scan — O(n) where n = number of routes // /api/v1/users/:id — check 1 // /api/v1/users/:id/posts — check 2 // /api/v1/teams/:id — check 3 // ...200 more checks... // forge/server: radix trie — O(k) where k = URL length // /api/v1/ // ├── users/ // │ └── :id // │ └── /posts // └── teams/ // └── :id // // Three node traversals regardless of total route count.

In benchmarks, this makes forge/server's routing 3-5x faster than Express at scale. But performance is just the beginning. The real advantage is architectural clarity.

WebSocket Without the Baggage

WebSocket support is arguably the most glaring omission in Express. Real-time communication is not a niche requirement — it is fundamental to modern applications. Chat, notifications, live dashboards, collaborative editing, multiplayer games — all require WebSocket.

The standard answer is to install ws or socket.io. Both are separate servers that you have to wire up alongside Express, sharing the same HTTP server instance through awkward upgrade handling. Error handling, authentication, and middleware do not carry over. You are running two servers pretending to be one.

forge/server implements WebSocket per RFC 6455 as a first-class feature. WebSocket routes share the same middleware pipeline, the same authentication layer, and the same error handling as HTTP routes:

// WebSocket with authentication and rooms app.ws('/chat/:room', { middleware: [authRequired], onConnect(socket, ctx) { socket.join(ctx.params.room); socket.to(ctx.params.room).emit('user:joined', ctx.user.name); }, onMessage(socket, data, ctx) { socket.to(ctx.params.room).emit('message', { user: ctx.user.name, text: data, timestamp: Date.now(), }); }, });

Notice how ctx.params and ctx.user work identically to HTTP routes. The authRequired middleware runs on WebSocket connections the same way it runs on HTTP requests. One mental model. One auth layer. One error handling pipeline.

Built-in GraphQL Engine

Apollo Server is a heavyweight. It pulls in dozens of transitive dependencies, has its own plugin system that conflicts with your server's plugin system, and introduces a second server lifecycle you have to manage. For many teams, the complexity of running Apollo is greater than the complexity of the business logic behind it.

forge/server includes a lightweight GraphQL engine that supports queries, mutations, subscriptions, schema stitching, and directive-based authorization — all through the same server instance:

app.graphql('/graphql', { typeDefs: ` type User { id: ID! name: String! posts: [Post!]! } type Query { user(id: ID!): User users(limit: Int = 20): [User!]! } type Mutation { createUser(name: String!): User! } type Subscription { userCreated: User! } `, resolvers: { Query: { user: (_, { id }) => db.users.find(id), users: (_, { limit }) => db.users.list({ limit }), }, }, });

Task Queues and Cron Without Redis

BullMQ is the standard job queue for Node.js applications. It works well, but it requires a running Redis instance, which means managing another piece of infrastructure, another failure point, and another thing to monitor.

forge/server provides an in-process task queue for workloads that do not need distributed processing (which is the vast majority of workloads), and a cron scheduler for recurring tasks:

// Task queue — in-process, no Redis needed app.queue.define('sendWelcomeEmail', async (job) => { await mailer.send({ to: job.data.email, template: 'welcome', vars: { name: job.data.name }, }); }); // Enqueue from any route handler app.post('/api/register', async (ctx) => { const user = await db.createUser(ctx.body); app.queue.enqueue('sendWelcomeEmail', { email: user.email, name: user.name }); return ctx.json(user, 201); }); // Cron — built-in scheduler app.cron.schedule('cleanup-expired-sessions', '0 */6 * * *', async () => { await db.sessions.deleteExpired(); });

Observability: Traces and Metrics Built-In

In the Express world, adding observability is an afterthought. You install prom-client for Prometheus metrics, some OpenTelemetry SDK packages for tracing, and a logging library. Each instruments the application differently. Correlating a trace with a log entry with a metric requires manual plumbing.

forge/server has OpenTelemetry-compatible tracing and Prometheus-format metrics built directly into the request pipeline. Every request automatically gets a trace ID. Every route handler automatically records latency histograms. Structured logs automatically include trace context:

// Automatic per-route metrics at /metrics // http_request_duration_seconds{method="GET",route="/api/users/:id",status="200"} // http_requests_total{method="GET",route="/api/users/:id",status="200"} // Automatic structured logging with trace context // {"level":"info","traceId":"abc123","spanId":"def456", // "method":"GET","path":"/api/users/42","status":200,"latency":12}

The Plugin System and DI Container

Express middleware is a flat pipeline. There is no lifecycle, no dependency injection, no way for one middleware to declare that it depends on another. This leads to brittle ordering requirements: "Make sure CORS runs before auth, auth runs before rate limiting, and the error handler is registered last."

forge/server uses a plugin system with explicit dependency declarations and a built-in dependency injection container:

const authPlugin = { name: 'auth', depends: ['jwt'], register(app, options) { app.di.register('authService', () => new AuthService(options)); app.use(async (ctx, next) => { ctx.user = await app.di.resolve('authService').verify(ctx); await next(); }); }, }; app.register(authPlugin, { strategy: 'bearer' });

The framework resolves plugin dependencies automatically. If auth depends on jwt, the JWT plugin is guaranteed to be initialized first. No more middleware ordering bugs. No more "did you remember to add CORS before the routes?"

Why Not Just Use Fastify?

Fastify is the best alternative to Express in the npm ecosystem, and we have enormous respect for it. But Fastify still follows the same model: it is a routing layer that you extend with plugins from separate packages. You still need separate packages for WebSocket, GraphQL, task queues, and observability. Each is maintained by a different team with a different release cadence.

forge/server takes the fully integrated approach. One team. One codebase. One release. Everything tested together. Everything documented together. Everything designed together.

"A modern server framework should not require you to install eleven packages to handle the same things every server handles."

Build Your Server the Modern Way

HTTP, WebSocket, GraphQL, Cron, TaskQueue, DI, Tracing, Metrics. One import. Zero external dependencies.

Read the Docs Request Early Access

HBForge is currently available exclusively for enterprise clients. Opening to the Developer Community on June 25, 2026. Contact kr@hyperbridge.in for early access.