Forem: Artem M

What If the Model Was the Source of Truth

Artem M — Wed, 11 Mar 2026 16:51:15 +0000

Recommended reading: The DTO problem — the class-validator pain points that motivate Atscript's approach.

The previous article showed how class-validator DTOs duplicate the same truth across TypeScript types, decorator stacks, and nested class hierarchies. Zod moves that truth into a schema DSL. Both work — but both still require a separate description of data that lives apart from your types.

Atscript takes a different path. Instead of bridging types and validation after the fact, it makes the model itself the single source — for types, validation, database schema, UI metadata, and anything else your stack needs.

This article is a quick tour of what Atscript is and why it exists.

One file, many outputs

Here is a user model in Atscript:

// user.as
export type Email = string.email
export type PositiveInt = number.int & number.positive

export interface User {
  @meta.label 'Full Name'
  @expect.minLength 2
  name: string

  email: Email

  @expect.min 13
  age: PositiveInt

  status: 'active' | 'inactive'
}

From this single .as file, Atscript generates:

TypeScript types — fully typed interfaces you import like any other module
Runtime validation — constraints enforced automatically
JSON Schema — for API documentation or contract testing
Runtime metadata — labels, descriptions, and custom annotations accessible programmatically

Semantic types replace decorator noise

In class-validator, you write @IsEmail() on a string. In Zod, you write z.string().email(). In both cases, the fact that something is an email lives outside the type system — in a decorator or a method chain.

Atscript builds meaning into the type itself:

string.email     // validates email format
string.uuid      // validates UUID
string.date      // validates date strings
number.int       // integer only
number.positive  // non-negative (>= 0)
number.timestamp // millisecond timestamp

These are semantic types — primitive extensions that carry validation constraints by definition. string.email is not a string with a decorator attached. It is a type that means "email" at every level: compile time, runtime validation, and metadata.

The Email and PositiveInt aliases from the example above are reusable domain types built from these primitives. You can use them anywhere — as interface properties, function parameters, or building blocks for larger models. The validation travels with the type.

Learn more about semantic types

Annotations attach metadata, not just validation rules

Most validation libraries stop at constraints. Atscript's annotation system goes further — it attaches any kind of metadata to your model:

export interface Product {
  @meta.label 'Product Name'
  @meta.description 'Display name shown to customers'
  @meta.example 'Wireless Headphones'
  @expect.minLength 1
  @expect.maxLength 200
  name: string

  @meta.label 'Price'
  @meta.sensitive
  cost: number.positive

  @ui.component 'select'
  @ui.placeholder 'Choose a category'
  category: 'electronics' | 'clothing' | 'food'
}

@expect.* handles validation. @meta.* handles labels, descriptions, examples, sensitivity markers. @ui.* hints at form rendering. All on the same model, all accessible at runtime through a single metadata API.

Learn more about annotations

Nested structures just work

One of the sharpest pains with class-validator is nested objects. Each one needs its own class, @ValidateNested(), and @Type(() => ClassName) wiring. Forget the @Type() decorator and validation silently skips the nested object.

In Atscript, nesting is just... nesting:

export interface Address {
  street: string
  city: string
  @expect.pattern "^[0-9]{5}$"
  zip: string
}

export interface Order {
  email: string.email
  items: OrderItem[]
  shipping: Address
  billing?: Address
}

No wiring. No class-transformer. Optional fields are optional because of ?. Arrays validate each item automatically.

Ad-hoc annotations: metadata without modifying the model

Sometimes you need different metadata for the same model in different contexts — a user model needs one set of labels for an admin panel and another for a public registration form. Atscript handles this with ad-hoc annotations:

import { User } from './user'

export annotate User as AdminUserView {
  @meta.label 'Administrator Name'
  @ui.order 1
  name

  @meta.label 'Admin Email'
  @ui.order 2
  email
}

This creates a new annotated variant of User without touching the original definition. The type stays the same; the metadata changes. Multiple views, one model.

Learn more about ad-hoc annotations

Validation is built in, not bolted on

Every Atscript type comes with a .validator() method:

import { Order } from './order.as'

const validator = Order.validator()

if (validator.validate(data)) {
  // data is narrowed to Order type
  processOrder(data)
} else {
  console.log(validator.errors)
  // [{ path: 'shipping.zip', message: '...' }]
}

Errors include full dot-path locations (shipping.zip, items.0.productId), so you know exactly what failed and where.

Need partial validation for updates? No extra classes required:

// Top-level partial
Order.validator({ partial: true }).validate(data)

// Deep partial — nested fields optional too
Order.validator({ partial: 'deep' }).validate(data)

Learn more about validation

The plugin system makes it extensible

Atscript is not a monolithic tool. The core parses .as files into an AST. Everything else — TypeScript generation, database adapters, validation — is a plugin.

// atscript.config.mts
import ts from '@atscript/typescript'

export default defineConfig({
  plugins: [ts()]
})

The TypeScript plugin ships first, but the architecture is language-agnostic. The same .as model could generate Python dataclasses, Go structs, or OpenAPI specs — each through its own plugin.

You can also extend the type system itself. Need a string.phoneUS semantic type for your project? Define it in the config:

export default defineConfig({
  primitives: {
    string: {
      extensions: {
        phoneUS: {
          type: 'string',
          documentation: 'US phone number',
          expect: {
            pattern: ['^\\d{10}$', '', 'Must be 10 digits']
          }
        }
      }
    }
  }
})

Now string.phoneUS is a first-class semantic type with built-in validation — usable in any .as file across your project.

Learn more about plugins

Database annotations live on the same model

Atscript is not an ORM. But it does let you describe database concerns on the same model that handles types and validation:

@db.table 'users'
export interface User {
  @meta.id
  @db.default.fn 'uuid'
  id: string

  @db.index.unique 'email_idx'
  email: string.email

  name: string

  @db.default.fn 'now'
  createdAt?: number.timestamp.created
}

From this, database adapters (SQLite, MongoDB) can generate schemas, run migrations, and provide type-safe CRUD — all derived from the same model that already handles your TypeScript types and validation.

The database layer is still experimental and the API may change — but the point here is that Atscript's annotation system is open-ended enough to carry database metadata alongside everything else, without the model becoming a framework-specific artifact.

Learn more about database integration

Not a validator — a model language

class-validator validates. Zod validates. Atscript describes.

The .as file is a data model definition — and validation, metadata, database schema, and whatever else your plugins need all fall out of that definition naturally.

Getting started

Atscript has a VSCode extension with syntax highlighting and diagnostics, and a CLI for compilation.

The quick start guide covers installation and first model in under five minutes.

This is the last article in the series. It started with a router benchmark, moved through request context, backend composables, multi-transport events, framework design, performance, and the DTO problem — and ended here, at the data model layer. If any of that caught your attention, the Atscript docs are the next step.

The DTO Problem in NestJS: Too Many Classes, Too Many Decorators

Artem M — Wed, 11 Mar 2026 16:51:11 +0000

Recommended reading: Moost without the ceremony — the NestJS comparison that sets up the context for this article.

Every NestJS project starts with a clean DTO. A name, an email, a password — three decorators, one class. It looks fine.

Then the product grows. Nested addresses, arrays of line items, conditional fields, update variants. Each nested shape needs its own class. Each property needs its own decorator stack. Each class needs its own file. What started as a clean validation layer becomes a parallel type system that you maintain by hand.

The problem is not decorators by themselves. The problem is duplicating the same truth across TypeScript types, DTO classes, and validation rules — and watching that duplication scale with every feature.

It starts simple enough

Here is a standard NestJS signup DTO. Nothing unusual:

import { IsString, IsEmail, IsNotEmpty, MinLength } from 'class-validator'

export class CreateUserDto {
  @IsString()
  @IsNotEmpty()
  name: string

  @IsEmail()
  @IsNotEmpty()
  email: string

  @IsString()
  @MinLength(8)
  password: string
}

Three fields, six decorators. Already more annotation than logic, but manageable. This is the example every NestJS tutorial shows, and it looks clean because the payload is flat.

Real payloads are not flat.

Nested objects force you into a class-per-shape pattern

The moment a payload has a nested object — an address, a billing section, a list of items — class-validator requires a separate class for each one. There is no inline syntax. Every nested shape must be extracted, named, decorated, and wired up.

Here is a typical e-commerce order DTO:

import {
  IsString, IsInt, IsEmail, IsOptional,
  IsArray, ArrayNotEmpty, ValidateNested,
  Min, MinLength, Matches,
} from 'class-validator'
import { Type } from 'class-transformer'

export class OrderItemDto {
  @IsString()
  @MinLength(1)
  productId: string

  @IsInt()
  @Min(1)
  quantity: number
}

export class AddressDto {
  @IsString()
  street: string

  @IsString()
  city: string

  @IsString()
  @Matches(/^[0-9]{5}$/)
  zip: string
}

export class CreateOrderDto {
  @IsEmail()
  customerEmail: string

  @IsArray()
  @ArrayNotEmpty()
  @ValidateNested({ each: true })
  @Type(() => OrderItemDto)
  items: OrderItemDto[]

  @ValidateNested()
  @Type(() => AddressDto)
  shipping: AddressDto

  @IsOptional()
  @ValidateNested()
  @Type(() => AddressDto)
  billing?: AddressDto
}

Three classes, eighteen decorators, two package imports. And this is still a simple order — no discount rules, no gift options, no metadata.

Notice the wiring tax. @ValidateNested() alone does nothing — you must pair it with @Type(() => ClassName) from class-transformer, otherwise validation silently skips the nested object. For arrays, add { each: true }. For optional nested fields, stack @IsOptional() on top. Forget any of these and validation breaks without a clear error.

This is not a bug in class-validator. It is the design. The library validates class instances, so every nested shape must be a class. TypeScript's structural typing does not help here — class-validator needs runtime class identity.

Now add Swagger — and the decorators triple

In real NestJS projects, DTOs do not just validate. They also generate API documentation. That means every property needs Swagger decorators too:

import { ApiProperty, ApiPropertyOptional } from '@nestjs/swagger'
import { IsString, IsEmail, IsNotEmpty, IsOptional, MinLength } from 'class-validator'

export class CreateUserDto {
  @ApiProperty({ description: 'Full name', example: 'Jane Doe' })
  @IsString()
  @IsNotEmpty()
  name: string

  @ApiProperty({ description: 'Email address', example: 'jane@example.com' })
  @IsEmail()
  @IsNotEmpty()
  email: string

  @ApiProperty({ description: 'Password (min 8 chars)', example: 'securepass' })
  @IsString()
  @MinLength(8)
  password: string

  @ApiPropertyOptional({ description: 'Phone number' })
  @IsOptional()
  @IsString()
  phone?: string
}

Four properties, twelve decorators. Each property declares its truth three times: once as a TypeScript type, once for validation, once for documentation. The NestJS Swagger CLI plugin can infer some @ApiProperty() annotations automatically, but it does not remove the need for validation decorators — and once you need custom descriptions, examples, or explicit types, you are back to manual annotation.

This is the everyday reality of a NestJS codebase at scale. Not the three-field tutorial example — the fifty-DTO project where every API change means editing decorator stacks across multiple files.

Update DTOs: same shape, different optionality

NestJS provides PartialType() to derive update DTOs from create DTOs:

import { PartialType } from '@nestjs/mapped-types'

export class UpdateUserDto extends PartialType(CreateUserDto) {}

This works for flat objects. But for nested payloads — where you want to partially update an address inside an order — PartialType() only makes top-level fields optional. The nested AddressDto still requires all its fields. You end up with separate UpdateAddressDto, PatchOrderDto, and so on — more classes, more files, more maintenance.

class-validator has no concept of deep partial validation. Every variation of optionality requires a new class.

Primitive validation does not exist

Here is something class-validator cannot do: validate a standalone value that is not a class property.

Want a reusable "validated email" type that you can use across DTOs and as a direct handler argument? In class-validator, you cannot. Every validated value must live inside a class:

// This is the only way to validate a single email
class EmailDto {
  @IsEmail()
  value: string
}

// You cannot validate a bare string
// You cannot reuse "validated email" as a type

This means you cannot build a vocabulary of validated primitives — Email, PositiveInt, UUID — and compose them. Every DTO must redeclare the same @IsEmail(), @IsInt(), @Min(0) stacks on every property where the rule applies. The duplication is baked into the design.

The real cost is maintenance

None of these problems matter in a three-endpoint app. They matter at scale.

A mid-size NestJS API — fifty endpoints, nested payloads, Swagger docs — easily has a hundred DTO classes. Each one is a hand-maintained bridge between the TypeScript type you think you have and the runtime validation that actually runs. Each one can drift. Each one is a place where a missing @Type() or a forgotten @IsOptional() silently breaks validation.

The community knows this. Libraries like nest-dto and nestjs-swagger-dto exist specifically to reduce the decorator tax by composing multiple decorators into one. The NestJS team added a Swagger CLI plugin to auto-infer some annotations. Developers have written articles titled "Why you should not use class-validator in NestJS". These are all symptoms of the same underlying design constraint.

What if the type was the validation?

class-validator bridges this gap with decorators. Zod bridges it with a schema DSL. Both work, but both require a separate description of data that your TypeScript types already express.

Atscript takes a different approach: validation is part of the type definition itself.

Here is the same order payload:

// order.as
export interface OrderItem {
  @expect.minLength 1
  productId: string
  @expect.min 1
  quantity: number.int
}

export interface Address {
  street: string
  city: string
  @expect.pattern "^[0-9]{5}$"
  zip: string
}

export interface CreateOrder {
  email: string.email
  items: OrderItem[]
  shipping: Address
  billing?: Address
}

One file. No @IsString() on things already typed as string. No @ValidateNested() + @Type() wiring. No class-transformer import. Nested structures validate automatically because the type already describes them. Optional fields are optional because of ?, not because of an @IsOptional() decorator.

The number.int and string.email are semantic types — they carry built-in validation constraints. You do not annotate what the type system already expresses.

Reusable validated primitives

Atscript lets you define validated types once and use them everywhere:

export type Email = string.email
export type PositiveInt = number.int & number.positive

These are not wrapper classes. They are types that validate. Use them as property types, function parameters, or compose them with &:

import { Email } from './types.as'

@Controller('newsletter')
export class NewsletterController {
  @Post()
  async subscribe(@Body() email: Email) {
    // email is validated automatically
    return this.newsletter.subscribe(email)
  }
}

A single Email type, used directly as a handler argument, validated at runtime by the framework. No DTO class, no decorator stack, no wrapper.

Deep partial validation without extra classes

Remember the update DTO problem? Atscript handles it with a validator option, not a new class:

// Top-level partial — missing required fields are OK
CreateOrder.validator({ partial: true }).validate(data)

// Deep partial — nested fields are optional too
CreateOrder.validator({ partial: 'deep' }).validate(data)

// Custom — partial only for specific paths
CreateOrder.validator({
  partial: (type, path) => path.startsWith('shipping'),
}).validate(data)

One model, multiple validation modes. No UpdateOrderDto, no PatchAddressDto, no class hierarchy.

For context: Zod also had deep partial support, but deprecated .deepPartial() in v3 and removed it in v4 with no built-in replacement — a pain point with over 100 reactions from the community. class-validator never had the concept at all.

This is not just another validator

The examples so far compare validation syntax. But the real difference is scope.

class-validator validates. Zod validates. Atscript describes. The same .as file that carries validation constraints also carries labels for UI, database annotations, API documentation metadata — anything your model needs to express. One definition, shared across the stack.

That is the topic for the next article: what happens when the model becomes the source of truth for your entire application, not just the validation layer.

If your NestJS project has more DTO files than feature files, the tool is not the problem — the pattern is. The next article steps back from validation entirely and looks at what Atscript actually is: a model-first type language that makes validation just one of many outputs from a single definition.

Read next: Atscript: model-first — What happens when the model becomes the source of truth for types, validation, database schema, and UI metadata.

Power of NestJS, More Throughput

Artem M — Wed, 11 Mar 2026 16:51:08 +0000

Recommended reading: Moost without the ceremony — the framework architecture being benchmarked here.

Performance claims from framework authors usually mean a hello-world endpoint. One route, no auth, no cookies — nothing like a real app.

This benchmark tests the full HTTP lifecycle: 21 routes, cookie parsing (~20 cookies per request), auth guards, body parsing, error responses — all through each framework's DI layer. Traffic is weighted to match real SaaS patterns. Full source: prostojs/router-benchmark.

DI overhead: 6% vs 12%

DI framework	Base layer	Base req/s	With DI	Overhead
Moost	Wooks	70,332	66,049	6%
NestJS (Fastify)	Fastify	68,273	60,196	12%
NestJS (Express)	Express	47,147	42,359	10%

Same features — decorators, DI, guards, interceptors. Moost's DI costs roughly half of what NestJS's does.

Overall throughput

Moost is ~10% faster than NestJS on Fastify across 20 weighted scenarios. But the overall number hides the real story.

Cookie-auth routes: 14% faster

The bulk of SaaS traffic is cookie-authenticated reads. Wooks parses cookies lazily — a request carries ~20 cookies, but the handler needs one or two. NestJS parses the entire jar upfront.

Attack traffic: 3x faster

Express and Fastify wait for the full request body to arrive before any middleware or guard runs. Wooks fires the handler as soon as the headers are received — so a guard can reject bad credentials before the body even reaches the server. On bot/scanner traffic sending large payloads with bad auth, that is a 3x difference (29k vs 9k req/s).

404s follow the same pattern — Moost is ~40% faster because NestJS routes them through the exception filter pipeline.

Where NestJS wins

NestJS (Fastify) is faster on set-cookie responses (48k vs 43k — Fastify's serialization is optimized) and small POST bodies (50k vs 45k — Fastify's request pipeline is tightly tuned). On simple static GETs, they are nearly identical.

Add a database and the gap compresses

With simulated Redis calls (~1ms) per authenticated handler, the 10% gap drops to 2.5%. Database I/O dominates. Choose your framework for developer experience, not benchmarks.

One exception: attack traffic stays 3x faster — early rejection pays off regardless of what the happy path does.

Less framework, more throughput

The previous article showed that Moost gives you NestJS ergonomics without the module ceremony. The thinner architecture is not just simpler — it is also faster under realistic load.

But performance is only one kind of framework overhead. The other is the code you write every day — DTOs, validation, schema definitions. That is what the next article tackles.

Read next: The DTO problem — Why class-validator DTOs become a maintenance nightmare at scale, and what a different approach looks like.

NestJS Ergonomics, Less Boilerplate

Artem M — Wed, 11 Mar 2026 16:51:04 +0000

Recommended reading: Backend composables and One pattern across events — the composable and multi-transport foundation Moost builds on.

NestJS got a lot of things right. Decorator-driven routing, constructor-based DI, interceptors with clear lifecycle phases, pipes that validate before the handler runs. Genuinely good ideas.

But NestJS makes you deal with all of its complexity on day one. Before you write a single handler, you need modules, provider arrays, import/export wiring, scope declarations. The framework does not have a simple mode — it has one mode, and that mode assumes your app is already complex.

What if the framework started simple and only grew more sophisticated when your app actually needed it?

Three files before your first handler

A basic user CRUD with one guard. Here is the minimum NestJS setup:

// users.module.ts
@Module({
  imports: [AuthModule],
  controllers: [UsersController],
  providers: [UsersService],
  exports: [UsersService],
})
export class UsersModule {}

// users.controller.ts
@UseGuards(JwtGuard)
@Controller('users')
export class UsersController { ... }

// app.module.ts
@Module({
  imports: [UsersModule, AuthModule, ConfigModule.forRoot()],
})
export class AppModule {}

Three files before any business logic. And every new feature starts the same way — another module, another provider array, another import/export cycle. The complexity is the same whether you are building a weekend prototype or a production system.

Same app, no ceremony

Here is the same app in Moost:

import { Moost, Controller, Injectable } from 'moost'
import { MoostHttp, Get, Post, Param, Body } from '@moostjs/event-http'

@Injectable()
class UsersService {
  async getUser(id: string) {
    return db.users.findById(id)
  }

  async createUser(data: CreateUserDTO) {
    return db.users.create(data)
  }
}

@Controller('users')
class UsersController {
  constructor(private users: UsersService) {}

  @Get(':id')
  async getUser(@Param('id') id: string) {
    return this.users.getUser(id)
  }

  @Post()
  async createUser(@Body() data: CreateUserDTO) {
    return this.users.createUser(data)
  }
}

const app = new Moost()
app.adapter(new MoostHttp()).listen(3000)
app.registerControllers(UsersController).init()

No modules. No provider arrays. The DI container resolves UsersService from the constructor signature — mark it @Injectable() and it works. Services are singletons by default (add 'FOR_EVENT' when you need per-request instances). This is the entire app — not a stripped-down demo.

A guard is one function, not three files

In NestJS, a guard implements CanActivate, gets registered as a provider in a module, and attached via @UseGuards(). Three concepts, three files worth of wiring, from the first protected route.

In Moost, a guard is a function:

const jwtGuard = defineAuthGuard(
  { bearer: { format: 'JWT' } },
  (transports) => {
    if (!transports.bearer) {
      throw new HttpError(401, 'Missing token')
    }
    verifyJwt(transports.bearer)
  }
)

Attach it to a controller, a method, or the whole app:

@Intercept(jwtGuard)
@Controller('users')
class UsersController { ... }

// or globally
app.applyGlobalInterceptors(jwtGuard)

No separate guard class, no module registration, no APP_GUARD token. One function, one decorator — and it scales to fifty routes without new abstractions.

Interceptors without the middleware puzzle

Most apps start without interceptors. When logging, error formatting, or response transformation becomes necessary, Moost interceptors follow a clear priority chain:

BEFORE_ALL → BEFORE_GUARD → GUARD → AFTER_GUARD → INTERCEPTOR → CATCH_ERROR → AFTER_ALL

Each interceptor hooks into three moments — before the handler, after it, and on error:

@Interceptor()
class LoggingInterceptor {
  @Before()
  onBefore(@Url() url: string) {
    console.log(`→ ${url}`)
  }

  @After()
  onAfter(@Response() response: unknown) {
    console.log(`← ${JSON.stringify(response)}`)
  }

  @OnError()
  onError(@Response() error: Error, @Overtake() reply: TOvertakeFn) {
    console.log(`✗ ${error.message}`)
    reply({ error: error.message })
  }
}

@Overtake() gives a reply function to short-circuit the response — useful for returning a formatted error instead of letting the exception propagate. Skip it and the normal flow continues. No implicit next() chain.

You can also define interceptors as plain functions — defineBeforeInterceptor(), defineAfterInterceptor(), defineErrorInterceptor(). Use whichever style fits the complexity of the task.

Custom decorators scale from one line to full DI

Every real app eventually needs custom decorators — @Roles('admin'), @DisplayName(), @RateLimit(). This is where NestJS's coordination tax becomes most visible.

The canonical example: a @Roles decorator with a guard that checks it. In NestJS, this requires three coordinated pieces — a decorator that writes metadata, a guard class that reads it via Reflector, and a module registration:

// roles.decorator.ts
export const ROLES_KEY = 'roles'
export const Roles = (...roles: string[]) => SetMetadata(ROLES_KEY, roles)

// roles.guard.ts
@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(ctx: ExecutionContext): boolean {
    const roles = this.reflector.getAllAndOverride<string[]>(
      ROLES_KEY, [ctx.getHandler(), ctx.getClass()],
    )
    if (!roles) return true
    const user = ctx.switchToHttp().getRequest().user
    return roles.some(role => user?.roles?.includes(role))
  }
}

// app.module.ts
@Module({
  providers: [{ provide: APP_GUARD, useClass: RolesGuard }],
})
export class AppModule {}

Three files. The ROLES_KEY string ties decorator and guard together. The Reflector service reads metadata that SetMetadata wrote. The guard has to be registered globally through the module system.

In Moost, the same pattern has two levels — pick the one that matches your complexity.

When the guard needs DI (e.g., a RoleService to check permissions against a database):

type TRolesMeta = { roles: string[] }

const Roles = (...roles: string[]) =>
  getMoostMate<TRolesMeta>().decorate('roles', roles)

@Interceptor(TInterceptorPriority.GUARD)
class RolesGuard {
  constructor(private roleService: RoleService) {}

  @Before()
  async check() {
    const { getMethodMeta, getControllerMeta } = useControllerContext()
    const roles =
      getMethodMeta<TRolesMeta>()?.roles ||
      getControllerMeta<TRolesMeta>()?.roles
    if (!roles) return
    const user = getCurrentUser()
    if (!await this.roleService.hasRole(user, roles)) {
      throw new HttpError(403, 'Insufficient role')
    }
  }
}

Two pieces instead of three — no module registration, no APP_GUARD token, no Reflector injection. Metadata access is type-safe through TRolesMeta, and getMoostMate().decorate() writes at the right level (method or class) automatically.

When the guard does not need DI — the whole thing collapses into one function:

const RequireRole = (role: string) => {
  const guard = defineBeforeInterceptor(() => {
    const user = getCurrentUser()
    if (!user?.roles.includes(role)) {
      throw new HttpError(403, `Role "${role}" required`)
    }
  }, TInterceptorPriority.GUARD)
  return Intercept(guard)
}

The decorator is the guard. One function, no metadata, no separate class. Use it the same way:

@RequireRole('editor')
@Controller('articles')
class ArticleController {
  @RequireRole('admin')
  @Delete(':id')
  remove() { ... }
}

Custom parameter resolvers follow the same pattern. A @DisplayName() decorator that reads from the body:

const DisplayName = () => Resolve(async () => {
  const { parseBody } = useBody()
  const body = await parseBody<{ fullName?: string; name?: string }>()
  return body.fullName || body.name
}, 'displayName')

NestJS has createParamDecorator with ExecutionContext. Moost has Resolve() with composables. Both work — but Resolve() gives you access to the same composable runtime your handlers use, so custom decorators compose with the rest of the app naturally.

The pattern holds: start with built-in decorators. Write a one-line Resolve() when you need a custom parameter. Write a one-function guard when you need role checks. Grow into class-based interceptors with DI when the logic demands it. Each step is there when you reach for it.

Different config per branch, no module gymnastics

This is where NestJS modules earn their keep. Different parts of the app sometimes need different instances of the same provider — an HttpClient pointed at different APIs, a logger with different prefixes. NestJS solves this with dynamic modules: forRoot, forRootAsync, forFeature. Powerful — but you pay for this machinery from the very first module, whether you need branched config or not.

In Moost, the controller tree is the scoping mechanism:

@Provide(HttpClient, () => new HttpClient('https://users-api.internal'))
@Controller('users')
class UsersController {
  constructor(private http: HttpClient) {}
  // this.http → users-api.internal
}

@Provide(HttpClient, () => new HttpClient('https://payments-api.internal'))
@Controller('payments')
class PaymentsController {
  constructor(private http: HttpClient) {}
  // this.http → payments-api.internal
}

@Provide scopes a provider to the controller and its entire subtree. Same class, different instances — no modules needed. And the DI engine is fully async, so wiring an async dependency is just an async factory:

@Provide(HttpClient, async () => {
  const { instantiate } = useControllerContext()
  const config = await instantiate(ConfigService)
  return new HttpClient(config.get('API_URL'))
})
class App extends Moost {}

No forRootAsync, no imports array, no separate inject declaration. instantiate() resolves any injectable class inside the factory with the same DI resolution the rest of the app uses.

Need to swap an entire implementation for a subtree? @Replace handles that:

@Replace(CacheService, RedisCacheService)
@Controller('cached')
class CachedController { ... }

Providers cascade down, any branch can override what it needs. But none of this exists in your codebase until the day your app actually has branched configuration.

Decorators and composables in the same handler

Moost adds decorator-driven structure — controllers, DI, interceptors — on top of Wooks. Every handler runs inside a Wooks event context, which means all composables from the previous articles work here too.

@Controller('reports')
class ReportsController {
  @Get(':id')
  async getReport(@Param('id') id: string) {
    // Decorator-resolved param ↑
    // Composable access ↓
    const { getId } = useEventId()
    const logger = useLogger()

    logger.info(`Report ${id} requested`, { eventId: getId() })
    return generateReport(id)
  }
}

Decorators and composables coexist naturally — most teams start with @Param(), @Body(), @Query() and reach for composables when they need custom request-scoped logic that does not fit a decorator shape.

This also means Moost inherits all Wooks adapters. The same mental model — controllers, DI, interceptors — works across HTTP, CLI, WebSocket, and workflow events, each with its own adapter-specific decorators like @Cli(), @Step(), or @Ws(). More on that in the previous article.

Less ceremony is not less structure

NestJS front-loads its entire conceptual surface: modules, dynamic modules, provider scopes, injection tokens, re-exports, forRoot/forRootAsync/forFeature — all before your app has a reason to need them. A weekend project and a 200-controller monolith start with the same ceremony.

Moost inverts that. Controllers and @Injectable() are enough for most apps. Guards, scoping, @Provide, @Replace, composables — each layer is there when you reach for it, and invisible until you do.

That thinner architecture is not just nicer to read. Moost sits on Wooks, which sits on @prostojs/router and a composable event core. No Express, no Fastify underneath — just Node's HTTP server and a thin routing + context layer. Less framework between the handler and the response means less overhead, less magic to debug, and less surface area for things to go wrong.

The next article digs into what that means when you actually measure it.

Read next: Moost performance — Real SaaS benchmark: 21 routes, cookies, auth guards, body parsing. How does less framework translate to throughput?

One Backend Pattern for HTTP, CLI, and Workflows

Artem M — Wed, 11 Mar 2026 16:51:00 +0000

Recommended reading: The request context problem and Backend composables — the context model and composable pattern this article builds on.

Most backend frameworks are HTTP frameworks that pretend otherwise.

They might support WebSockets as a plugin. CLI tooling lives in a separate package. Scheduled jobs get wired through a queue library with its own conventions. And if the same business action needs to run from an API endpoint and a CLI command and a scheduled job, you write three wrappers around the same logic.

Not because the logic is different. Because the framework assumed HTTP from the start.

That is the problem I hit after building the composables layer from the previous article. The composables worked great inside HTTP handlers — but the moment I needed the same action from a CLI command or a workflow step, the HTTP-shaped context leaked everywhere.

The duplication nobody talks about

A pattern most teams know but rarely name.

You build an API endpoint that generates a report:

app.post('/api/reports/generate', async () => {
  const user = await useCurrentUser().requireUser()
  const tenant = useTenant().current()
  const filters = useReportFilters().value()

  return generateReport({ user, tenant, filters })
})

Then someone needs the same report from a CLI tool for backfills. Then ops wants it as a scheduled job. Then a workflow step needs it too.

Each entry point gets its own wrapper: different context setup, different argument parsing, different error handling. The business logic is the same — everything around it is duplicated.

The usual fix is to extract a "service" and wire context manually per transport. That works, but it pushes context management back to the developer — exactly the problem composables were supposed to solve.

Transport is an edge concern

The insight behind Wooks: transport should be an edge concern, not the main architecture.

HTTP, CLI, WebSocket, workflow — just different ways an event enters the system. Once it arrives, the app needs the same things: identity, permissions, configuration, scoped state, logging.

Wooks adapters are thin edge layers that translate transport-specific input into a shared event context. Everything else — context creation, composable resolution — lives in one core.

One core, many adapters

Here is what the wiring looks like:

import { createHttpApp } from '@wooksjs/event-http'
import { createCliApp } from '@wooksjs/event-cli'
import { createWsApp } from '@wooksjs/event-ws'
import { createWfApp } from '@wooksjs/event-wf'

const http = createHttpApp()
const cli = createCliApp({}, http)   // shares the same Wooks instance
const ws = createWsApp(http)         // shares it too
const wf = createWfApp({}, http)     // and so does the workflow adapter

Each adapter registers handlers in its own namespace — HTTP on requests, CLI on parsed commands, WebSocket on messages, workflows on step triggers. But they all resolve composables like useRouteParams(), useEventId(), and useLogger() from the shared core.

HTTP, CLI, and workflows side by side

The same report from three entry points.

HTTP:

http.post('/reports/generate', async () => {
  const user = await useCurrentUser().requireUser()
  const filters = useReportFilters().value()

  return generateReport({ user, filters })
})

CLI:

cli.cli('reports generate', {
  description: 'Generate a report from the command line',
  options: [
    { keys: ['format', 'f'], description: 'Output format', value: 'pdf' },
  ],
  handler: async () => {
    const user = await useServiceAccount().get()
    const filters = useReportFilters().value()
    const format = useCliOption('format')

    const report = await generateReport({ user, filters })
    return writeReport(report, format)
  },
})

Workflow step:

wf.step('generate-report', {
  handler: async () => {
    const { ctx } = useWfState()
    const filters = useReportFilters().value()

    ctx().report = await generateReport({
      user: ctx().user,
      filters,
    })
  },
})

generateReport is the same function in all three cases. What changes is only what should change: how the user is identified, how arguments arrive, how output is delivered.

Each adapter brings its own composables

Each adapter adds transport-specific composables on top of the shared core:

HTTP (Wooks HTTP stack):

useRequest(), useCookies(), useAuthorization(), useUrlParams(), useBody()

CLI (@wooksjs/event-cli):

useCliOptions(), useCliOption(), useCliHelp(), useAutoHelp()

WebSocket (@wooksjs/event-ws):

useWsConnection(), useWsMessage(), useWsRooms()

Workflows (@wooksjs/event-wf):

useWfState() — access to workflow context, step input, resume state

Same pattern everywhere: call a composable, get a scoped value, no singletons, no manual threading.

Context flows through parent chains

Wooks event contexts support parent chains.

When a WebSocket connection starts from an HTTP upgrade, the WS context inherits the HTTP context. When a message arrives, it creates a child context under the connection.

HTTP upgrade context
  └── WS connection context
        └── WS message context

A composable in a message handler can read HTTP-level data (like the original auth header) through the parent chain — no manual wiring.

Workflows work the same way when you pass eventContext: current() from an HTTP handler. That link is explicit, not automatic, so workflows stay independent when triggered from CLI or scheduled jobs.

Scoped context with read-through inheritance. Not magic.

Where this pays off

Admin CLIs share permission logic with the API. Same composables, same rules — no separate auth setup.

Data repair scripts skip the boilerplate. A backfill CLI runs the same composables with a service account instead of reimplementing context from scratch.

Scheduled jobs need zero glue. The workflow adapter creates an event context, so cron-triggered steps call the same functions the API uses.

Live dashboards reuse data access. A WebSocket view shares composables with the REST API and adds room-based broadcasting through the WS adapter.

The pattern goes beyond built-in adapters

Wooks ships with HTTP, CLI, WebSocket, and workflow adapters. But the event core is not limited to those four.

Any event source — a message queue, a file watcher, a custom protocol — can be wrapped into a Wooks adapter. The adapter creates an event context, feeds it into the shared core, and from that point on, all composables just work. Same lazy resolution, same scoping, same caching.

The four built-in adapters are starting points, not boundaries. Wooks is not "another HTTP framework." It is an event-processing core, and HTTP is just one of its adapters.

Some teams want more structure

This lower-level power is valuable. But not every team wants to wire adapters and define composables from scratch.

Many teams want controllers, decorators, dependency injection — the kind of conventions that make onboarding fast and code predictable.

That is where Moost comes in — a higher-level framework built on Wooks that adds all of that without losing the composable event core underneath.

Read next: Moost without the ceremony — NestJS ergonomics without the module tax. Controllers, DI, and guards that start simple.

Stop Putting App Logic in Middleware

Artem M — Wed, 11 Mar 2026 16:50:56 +0000

Recommended reading: The request context problem — Why req became a junk drawer and what Wooks does differently.

In the previous article, I argued that request context is where backend frameworks quietly go wrong.

This one is the practical follow-up: what do you actually do instead?

Short answer: write composables for app logic.

Not for everything. Not instead of every low-level hook. But for a surprising amount of work that keeps ending up in middleware: current user, tenant, pagination, filters, parsed body, locale, permissions.

That kind of code is just app logic that needs access to request context.

Middleware became the default answer

In Express and Fastify, the default answer to most backend needs is still:

"Add middleware. Put the result on the request. Read it later."

Which is how apps end up with chains like this:

app.use(authMiddleware)
app.use(tenantMiddleware)
app.use(paginationMiddleware)
app.use(filterMiddleware)

app.get('/projects', (req, res) => {
  return res.json(listProjects({
    user: req.user,
    tenant: req.tenant,
    pagination: req.pagination,
    filters: req.filters,
  }))
})

This works. But it also means:

the handler depends on state that appeared from somewhere above
some of that work runs even when the route does not need it
testing means mocking a weirdly expanded request object
reusable app logic stays glued to HTTP conventions

At some point, middleware stops being an abstraction and starts being a storage strategy.

This does not belong in middleware

Some things genuinely belong in middleware: CORS, compression, transport logging, proxy handling, security headers. Boundary-level work. Middleware is fine there.

But "resolve the current user", "read pagination from query params", and "figure out the current tenant" are not boundary concerns. They are request-scoped values the app wants to ask for.

Look at it that way, and a lot of middleware starts looking like composables in disguise.

Ask for the context when you need it

Here is the same handler in Wooks:

app.get('/projects', async () => {
  const user = await useCurrentUser().requireUser()
  const tenant = useTenant().current()
  const pagination = usePagination().value()
  const filters = useProjectFilters().value()

  return listProjects({
    user,
    tenant,
    pagination,
    filters,
  })
})

Dependencies are finally visible where they are used. The handler does not care whether useCurrentUser() reads a token, hits a cache, or loads from a database. It asks for what it needs. And if it never asks for body parsing, body parsing never happens.

The whole model: ask for what you need, when you need it.

h3 deserves credit here too — it explored the same problem space in parallel. h3 went with a dedicated event object; Wooks went with AsyncLocalStorage. Both escape the old req mutation model. The difference is that in Wooks, app code calls composables directly instead of threading event through every helper.

Write your own composables

The built-in ones — useBody(), useCookies(), useAuthorization(), useUrlParams() — are useful on their own.

But the real payoff is writing app-level composables on top of them.

Here is a realistic useCurrentUser():

import { cached, defineWook } from '@wooksjs/event-core'
import { useAuthorization } from '@wooksjs/event-http'

const userSlot = cached(async (ctx) => {
  const { is, credentials } = useAuthorization(ctx)
  if (!is('bearer')) return null

  const token = credentials()
  if (!token) return null

  return findUserByToken(token)
})

export const useCurrentUser = defineWook((ctx) => ({
  getUser: () => ctx.get(userSlot),
  requireUser: async () => {
    const user = await ctx.get(userSlot)
    if (!user) throw new Error('Unauthorized')
    return user
  },
}))

Exactly the kind of logic that usually ends up in middleware. As a composable, it gains better properties:

reusable across any handler
request-scoped by default
the expensive part is cached automatically
invoked only when the handler actually needs it

Some composables are even simpler. Pagination, for example:

import { defineWook } from '@wooksjs/event-core'
import { useUrlParams } from '@wooksjs/event-http'

export const usePagination = defineWook((ctx) => {
  const search = useUrlParams(ctx).params()

  const page = Math.max(1, Number(search.get('page') ?? '1'))
  const limit = Math.min(100, Math.max(1, Number(search.get('limit') ?? '20')))

  return {
    value: () => ({ page, limit }),
  }
})

Just app logic living in the right place.

The beauty of lazy slots

Easy to miss if you only look at the handler API: what makes this pattern work is not defineWook() alone. It is the event core underneath — especially cached().

That userSlot above is not just a helper variable. It is a lazy, request-scoped slot:

if nobody asks for the current user, nothing runs
if three different layers ask for it, the lookup still runs once
the slot belongs to the current event, not some global singleton

Lazy by design, not by convention.

And you can layer bigger logic on top:

import { cached, defineWook } from '@wooksjs/event-core'

const permissionsSlot = cached(async (ctx) => {
  const user = await useCurrentUser(ctx).getUser()
  if (!user) return []

  return loadPermissions(user.id)
})

export const usePermissions = defineWook((ctx) => ({
  list: () => ctx.get(permissionsSlot),
  can: async (name: string) => {
    const permissions = await ctx.get(permissionsSlot)
    return permissions.includes(name)
  },
}))

Not a performance trick glued on later — this is the default model. The permissions lookup stays lazy, shared, and request-scoped. And because it is just another composable, the handler code stays clean.

Reuse composables across layers

The same composable works from different layers without turning into a global singleton mess:

async function requireAdmin() {
  const user = await useCurrentUser().requireUser()
  if (user.role !== 'admin') throw new Error('Forbidden')
}

app.get('/admin/projects', async () => {
  await requireAdmin()

  const user = await useCurrentUser().requireUser()
  const pagination = usePagination().value()

  return listProjects({
    ownerId: user.id,
    pagination,
  })
})

useCurrentUser() resolves against the same request context in both places. No two disconnected lookups just because two parts of the call stack asked for the same thing.

This is where composables stop being "nicer middleware" and become a genuinely better unit of backend reuse.

Composables are easier to test

This is where things get practical fast. A composable like usePagination() can be tested directly:

import { expect, it } from 'vitest'
import { prepareTestHttpContext } from '@wooksjs/event-http'

it('reads page and limit from query params', () => {
  const run = prepareTestHttpContext({
    url: '/projects?page=3&limit=50',
  })

  run(() => {
    expect(usePagination().value()).toEqual({
      page: 3,
      limit: 50,
    })
  })
})

No fake middleware chain. No custom req type gymnastics. No "did middleware X already run before middleware Y?"

Just test the thing you wrote.

Not only HTTP

Once app logic lives in composables backed by lazy event-scoped slots, the HTTP adapter stops being the center of the design.

Current user, permissions, event ID, logging, derived context — these stop looking like "HTTP framework features" and start looking like event-scoped building blocks.

That is where Wooks opens up. The next question is no longer "how do I do this in an HTTP handler?" It becomes: what happens when the same pattern works for WebSocket handlers, CLI commands, and workflows too?

Read next: One pattern across events — Same composables, same context model — across HTTP, CLI, WebSocket, and workflows.

Every HTTP framework gets request context wrong

Artem M — Wed, 11 Mar 2026 16:50:53 +0000

Recommended reading: I benchmarked five Node.js routers — the router benchmark that started this series.

After the router benchmark article, the obvious next topic should have been frameworks.

But the thing that kept bothering me for years was smaller, and somehow worse: request context.

Not routing. Not controllers. Not decorators.

req.

Or more precisely: what backend frameworks keep doing to req and res.

Three things always felt wrong:

app state kept leaking into req
middleware kept doing work nobody asked for yet
the same request-scoped value kept getting recomputed across different layers

That is the problem Wooks event core was built to fix.

Where is the request state?

What always felt wrong in Express and, to a large extent, Fastify, was this pattern:

middleware computes something
sticks it onto req
the next layer just hopes it is there

At first it is one property:

req.user = user

Then it becomes:

req.user = user
req.tenant = tenant
req.pagination = pagination
req.filters = filters
req.requestId = requestId

Now req is not really a request object anymore. It is an application context backpack.

Getting the right type for req was never as trivial as it should be. And every piece of middleware that needed to pass something downstream kept turning into "just add one more property."

That works, until it does not. Typing becomes awkward. Ownership becomes unclear. And every new piece of request-scoped state fights for a slot on an object that was never meant to carry the whole app.

Never precompute what nobody asked for

The second thing that clicked came from Vue 3.

I loved the composables model and kept thinking: backend frameworks should work like this too.

Not middleware that eagerly parses the body for every matching route. Just:

const { parseBody } = useBody()
const body = await parseBody()

And if the handler never asks for the body, the body never gets parsed.

The same applies to everything else: useCookies(), useAuthorization(), useUrlParams(), useCurrentUser().

Not "prepare everything up front, just in case." More like "resolve only what the current code actually needs."

That felt much closer to how request handling should work.

Invoke lazily, cache once

The third piece came a bit later.

In real request handling, code often asks for the same derived value more than once:

an auth guard needs the current user, then the handler needs it too, then a logger wants it again
one layer parses the body, another layer needs the parsed body too

That work should not run repeatedly. It should be cached for the lifetime of the current request.

Sounds obvious once you say it out loud, but most frameworks do not make it a natural default. Request-scoped computation should be lazy, shared, and cached — by design, not by discipline.

That is how Wooks was born

Wooks came from combining those three ideas — not from "let me build another HTTP framework."

Stop treating req as a junk drawer for app state
Use composables to access request data only when needed
Cache request-scoped computation so all layers share it

The result is Wooks event core:

every event gets a context
composables read from that context
repeated work is shared within the event lifetime

Instead of mutating req, the event context becomes the primitive.

What this looks like in practice

A typical HTTP route:

app.get('/projects', async () => {
  const requestId = useEventId().getId()
  const user = await useCurrentUser().require()
  const tenant = await useTenant().current()
  const filters = useProjectFilters().value()
  const pagination = usePagination().value()

  return listProjects({
    requestId,
    user,
    tenant,
    filters,
    pagination,
  })
})

The point is not that the handler is shorter. The point is:

no middleware randomly adding fields to req
nothing eagerly parsed "just in case"
every dependency visible where it is used
repeated computations shared automatically within the same event

No junk-drawer req. No eager middleware work. No repeated computation.

This is bigger than HTTP

What I wanted was not "better middleware." It was a better primitive for request-scoped work.

Once context is treated as a real system, HTTP is just one place where it becomes useful. The same idea extends to CLI commands, workflows, WebSocket events, and custom event types.

That is why I think of Wooks as an event core, not "some nicer Express wrapper."

Next up: composables in practice

The next article digs into the part that made this click for me — why backend composables are not just a cute API idea, but a genuinely better primitive than middleware for request-scoped logic.

Read next: Backend composables — What happens when you replace middleware with composables for request-scoped logic.

The Fastest Node.js Router? Only If You Measure It That Way

Artem M — Wed, 11 Mar 2026 16:50:49 +0000

Every router benchmark has a winner.

Conveniently, it is often the router favored by the person who ran the benchmark.

That is not always dishonest. Sometimes the benchmark is just too narrow, too flattering, or too cute to say anything useful about a real app.

Node.js routers are a perfect example.

You can build a chart where Hono looks unbeatable.
You can build one where trie routers look like the only serious option.
And you can build one where some other router suddenly jumps to the top.

Which is why I wanted to benchmark routers in a way that is a bit less flattering and a bit more annoying.

I tested:

But before the results, here is the only part that actually matters: what exactly was measured.

The raw benchmark code lives here: router-benchmark.

Worth noting: rou3 is not just some random router on a comparison chart. It powers H3 routing, Nitro is built around H3, and Nuxt server routes run on Nitro. So the chain is basically rou3 → H3 → Nitro → Nuxt.

The one benchmark rule that actually matters

Router benchmarks are often misleading because they do not measure the same work.

Some routers extract params eagerly. Others return internal structures that still need to be decoded. If the benchmark stops before that last step, the numbers look cleaner than reality — great for slides, less great for truth.

So my benchmark forces full lookup work:

match the route
extract params
handle static, parametric, wildcard, and miss cases
test short, long, and mixed route sets

A much fairer comparison, because real applications need the params, not just the match.

I also did not stop at one route table. The benchmark covers:

short routes
long enterprise-style routes
mixed route sets
a scaling run from 22 to 200 routes

Because "fastest router" on 22 shallow routes is a very different question from "what happens when the route table starts looking like a real backend?"

Hono is really fast — until it is not

Let’s get the obvious part out of the way: Hono is fast.

In the 22-route benchmark, Hono’s RegExpRouter led both the short-route and mixed-route variants. If your app has a small route table with lots of shallow paths, that result is real and worth respecting.

Here is the small-route snapshot: shallow routes, 22 total, full route match plus param extraction, 200k operations per test, averaged over 2 runs.

One glance: Hono looks excellent when the route set is small and shallow. That part of the "Hono is fast" story is absolutely real.

If the article ended here, the conclusion would be simple:

"Hono is the fastest router, congratulations everyone, time for lunch."

But that is exactly the kind of conclusion that makes router benchmarks misleading. So I kept pushing.

Deep routes change the leaders

The long-route benchmark looks more like the APIs I actually work with:

shared /api/v1/... prefixes
several nested segments
one to four params
realistic SaaS-style depth

At 22 routes, @prostojs/router took the lead:

@prostojs/router: about 9020 op/ms
Hono RegExpRouter: about 8250 op/ms
rou3: about 7157 op/ms
find-my-way: about 6283 op/ms

Already a different picture from the "Hono wins everything" headline.

Not all routers scale the same

The most revealing result was not the 22-route snapshot. It was the scale test.

Once the route table grows from 22 to 50 to 100 to 200 routes, the question shifts from "who wins this chart?" to "what happens when the app stops being a toy?"

At higher route counts, Hono's RegExpRouter stopped compiling for the deep-route case and fell back to TrieRouter — much slower in that workload.

That does not make Hono bad. It means its headline speed is workload-sensitive, which matters when people treat "the fastest router" as a law of physics.

There is another outcome here that deserves attention: find-my-way and rou3 scale really well. If your route table is going to grow large and predictable scaling is a top priority, the trie routers look excellent. A real advantage, not a footnote.

The honest summary is not "regex good" or "trie good." It is closer to:

Hono looks amazing in the flattering small-route case
@prostojs/router is especially strong on deep and parametric routes
find-my-way and rou3 stay impressively stable as route count grows

This next chart is the most important one in the article: deep enterprise-style routes, route counts growing from 22 to 200, full lookup work, 500k operations per point, averaged over 5 runs.

This chart matters more than any braggy headline.

It also highlights what makes @prostojs/router interesting: strong on deep and parametric routes, without sacrificing features to get there.

Router benchmarks are (mostly) sport

Here is the conclusion I came to after benchmarking full HTTP frameworks, not just routers.

Router benchmarks are useful — they reveal tradeoffs, expose scaling cliffs, and punish bad assumptions.

But they are overrated, because they isolate a cost that gets diluted fast in a real app.

The moment you add HTTP request handling, header and cookie parsing, body parsing, auth checks, validation, or database work — the router becomes a small part of total request cost.

That is what I saw in the related Wooks and Moost benchmarks: big router-level gaps shrink at framework level, then shrink again once real work enters the picture.

Wooks has a dedicated router benchmark analysis here:
wooks.moost.org/benchmarks/router.html

If someone picks a router entirely by a benchmark headline, they are probably optimizing the wrong thing.

This next chart moves one level up — from pure routing to full HTTP framework overhead. It comes from the Wooks benchmark using a realistic SaaS-style route mix with auth, cookies, headers, body parsing, and actual handlers.

Already smaller gaps than at the pure router level.

And this final chart adds real I/O: each authenticated request performs a local Redis operation — the kind of work that quickly dominates any routing difference in production.

Add real work, and the gap shrinks again.

Choose features, not speed

Once a router is fast enough, speed stops being the deciding factor.

What matters more:

correctness on tricky and encoded URLs
the route patterns you actually need
predictable params and wildcards
stable scaling without weird cliffs
solid TypeScript ergonomics

@prostojs/router sits in an interesting spot: top-tier performance while offering features many fast routers skip — regex-constrained params, multiple wildcards, optional params and wildcards, path builders, and correct URL handling.

That is also why this benchmark became the starting point for a bigger stack. I used @prostojs/router as the foundation for Wooks, because once routing is solved well enough, the next problem is far more interesting:

Where does request context actually live?

Not in benchmark charts. In real code — auth state, cookies, parsed bodies, tenant resolution, request IDs, and all the other things that get shoved into req, threaded through helpers, or quietly hidden in middleware.

That is what I want to dig into next.

Read next: The request context problem — Why req became a junk drawer and what happens when you stop treating it like one.

Do me lint! 🙋‍♂️ An easy way to setup ESLint in any project.

Artem M — Mon, 30 Dec 2024 21:23:55 +0000

ESLint

You’ve probably used ESLint (or at least heard of it) in your JavaScript or TypeScript projects. It’s a great tool to keep your code consistent and error-free, but setting it up is not that simple.

I want to share a cool little tool I found to make eslint setup in your project a just one command!

Why ESLint at all? 🤔

ESLint helps you:

Catch Bugs Early: It flags issues in your code before they become real problems.
Keep Things Consistent: Everyone on the team writes code the same way.
Write Better Code: Cleaner, more maintainable code is always a win.

Strict rules are great for catching problems early, but getting that setup right? That’s where things get tricky.

ESLint setup is hard

ESLint has so many rules, and while that’s awesome, it also makes setting it up a bit of a headache. You’ve got to:

Spend time figuring out what rules to use.
Test them to make sure they fit your codebase.
Deal with the sheer number of options (which can be pretty intimidating).

Meet `do-me-lint` 🪄

do-me-lint is a script you can run in your project, and it’ll generate an .eslintrc.yml file for you. The cool thing is, it analyzes your project and selects rules that actually make sense. Sure, it’s opinionated (in a good way), but the author spent a lot of time researching and testing these rules to ensure they work well for most projects.

Here’s how you use it:

Run this in your terminal (in your existing project):

   npx do-me-lint

That’s it! You’ll get a solid .eslintrc.yml file ready to go, along with all the necessary ESLint packages installed to streamline the selected rules.

Tweaking the Rules 🔨

Of course, no setup is perfect for everyone. Sometimes you’ll want to tone down a rule or turn it off completely. Do it in do-me-lint config:

Change Errors to Warnings: Create .domelintrc.yml and add the rule under relaxedRules:.

   relaxedRules:
     - import/no-default-export

Disable Rules Completely: Add the rule to ignoredRules:.

   ignoredRules:
     - import/no-default-export
     - '@typescript-eslint/class-methods-use-this'

Next time you run do-me-lint, it’ll apply your changes.

Is it a hidden gem? 💎

Honestly, do-me-lint feels like a hidden gem. It gets the job done and saves you a ton of time. If you’ve ever felt overwhelmed by ESLint setup, give it a try. It might just become one of your favorite tools 👍.

That’s all for now — happy linting! 🚀

Links

Project on GitHub.