Benchmarks: Moost vs NestJS

This isn't a hello-world benchmark. We tested the full HTTP lifecycle — routing, header parsing, cookie jars with ~20 cookies, authentication, body parsing, and response serialization — all running through each framework's decorator-based DI layer.

Moost and NestJS share the same programming model (decorators, DI, controllers), but Moost is built on Wooks instead of Express or Fastify. We wanted to know: how much does the DI framework itself cost?

Benchmark setup and methodology

Source code: prostojs/router-benchmark

Framework	HTTP Layer	Router	DI System
Moost	Wooks (@wooksjs/event-http)	@prostojs/router	@prostojs/mate + functional DI
NestJS (Fastify)	Fastify	find-my-way	@nestjs/core DI container
NestJS (Express)	Express	Express router	@nestjs/core DI container

We used autocannon (100 connections, 10 pipelining) across 20 test scenarios modeling a project management SaaS API with 21 routes. Traffic is weighted to reflect real-world patterns: public pages (20%), API calls with header auth (25%), browser routes with cookie auth (35%), and error responses (20%).

How Much Does DI Cost?

Both frameworks add overhead on top of their underlying HTTP layer. The difference is how much:

• Moost adds roughly 6% on top of raw Wooks
• NestJS adds 10–12% on top of raw Fastify/Express

For the underlying layer benchmarks, see Wooks HTTP and Router.

Overall Throughput

Across all 20 scenarios, Moost is about 10% faster than NestJS on Fastify and 56% faster than NestJS on Express.

Public & Static Routes

On simple static routes, Moost and NestJS (Fastify) are neck and neck. Fastify has a slight edge on login with set-cookie thanks to its highly optimized cookie serialization.

Header-Auth API Routes

Standard API routes with Bearer token auth are closely matched. Two interesting differences:

• Moost handles auth failures faster — Wooks short-circuits before allocating response resources
• NestJS (Fastify) handles small POST bodies faster — Fastify's request pipeline is tightly optimized for this path

Cookie-Auth Browser Routes

This is where Moost pulls ahead clearly — about 14% faster across cookie-authenticated routes. The reason: Wooks parses cookies lazily, only touching the ones your handler actually needs. NestJS parses the entire cookie jar upfront regardless.

Error Responses & Edge Cases

Two results stand out:

• 404 responses — Moost is about 40% faster because NestJS routes 404s through its exception filter pipeline
• Large body with bad auth — Moost is over 3x faster because Wooks skips body parsing entirely when authentication fails first. NestJS parses the full body before the guard rejects the request.

Where Each Framework Shines

Moost is faster when:

• Requests carry lots of cookies (lazy parsing pays off)
• Requests fail early (404s, auth rejections)
• Large request bodies arrive with bad credentials

NestJS (Fastify) is faster when:

• Responses set cookies (Fastify's serialization is fast)
• Handling small POST/PUT bodies (Fastify's request pipeline is very tight)

With Real Database Calls

In practice, your handlers do more than parse headers — they talk to databases. When we added simulated Redis calls (~1ms) to every handler, the picture changed:

With I/O in the mix, the gap between Moost and NestJS (Fastify) shrinks to just ~2.5%. The DI framework overhead becomes a rounding error next to actual business logic.

The bottom line

All three options are fast enough for production. Choose your framework for developer experience and architecture, not benchmarks. The real question is whether you prefer Moost's composable approach or NestJS's module system.

Why Moost

• Familiar patterns — same decorators and DI as NestJS, without the module boilerplate (@Module(), providers arrays, forRoot())
• Less DI overhead — roughly half the cost of NestJS's DI layer
• Built on Wooks — lazy evaluation, typed context, composable functions
• One architecture for everything — HTTP, CLI, WebSocket, and Workflows
• Powerful router — regex constraints, multiple wildcards, optional params, case-insensitive matching via @prostojs/router

See also: Router benchmark | Wooks HTTP benchmark

---

Source: prostojs/router-benchmark | Date: February 2026 | Method: autocannon, 100 connections, 10 pipelining, 0.5s/test, 20 scenarios