DEV Community: Mattia Carcione

Where Should Request Validation Live in a TypeScript Application?

Mattia Carcione — Wed, 07 Oct 2026 12:47:00 +0000

Where Should Validation Live in a TypeScript Application?

Validation looks simple.

A client sends a request. We validate the input. If something is wrong, we return an error.

But as an application grows, an architectural question becomes important:

Where should validation actually happen?

Should validation belong to the HTTP layer?

Should controllers validate requests?

Should the application layer validate commands?

And what happens when the same application logic is executed without HTTP?

This article explores the problem first, then the architectural solution, and finally how Xeno.JS implements that solution natively.

The problem

Imagine an e-commerce API with an endpoint:

POST /orders

The request body is:

{
  "items": [
    {
      "productId": "prod_123",
      "quantity": 2
    }
  ]
}

At the HTTP boundary, we obviously need to validate the input.

For example:

productId must be present
quantity must be an integer
quantity must be greater than zero
the items collection cannot be empty

A straightforward implementation is:

HTTP Request
     │
     ▼
Controller
     │
     ▼
Validate request
     │
     ▼
Application

This works.

The problem appears when the application becomes larger.

Validation becomes tied to the transport

Consider the same CreateOrder use case.

Today it is called through HTTP:

HTTP
  ↓
CreateOrder

Tomorrow it might also be called by:

CLI
  ↓
CreateOrder

or:

Queue
  ↓
CreateOrder

or:

Worker
  ↓
CreateOrder

If validation exists only inside the HTTP controller, we now have a problem.

We could end up with:

HTTP Controller
    └── HTTP validation

CLI
    └── CLI validation

Queue Consumer
    └── Queue validation

Worker
    └── Worker validation

The same application command now has multiple validation implementations.

That creates duplication and, more importantly, creates the possibility that different entry points validate the same operation differently.

The key question

Instead of asking:

"Is this HTTP request valid?"

we can ask:

"Is this application command valid?"

This is a much more useful question.

The application does not really care where the command came from.

It only cares about the command it is about to execute.

For example:

CreateOrderCommand

represents an application operation.

The command could come from HTTP, a queue, a CLI, or another adapter.

The validation rules for that command should remain the same.

Moving validation closer to the application

A better architecture is:

HTTP
 │
 ▼
Controller
 │
 ▼
CreateOrderCommand
 │
 ▼
Application
 │
 ├── Validation
 │
 └── Handler

Now validation belongs to the execution of the application command rather than to one particular transport.

The same command can therefore be validated regardless of how it entered the system.

HTTP ─────┐
          │
CLI ──────┤
          │
Queue ────┼──► CreateOrderCommand
          │          │
Worker ───┘          ▼
                Validation
                     │
                     ▼
                  Handler

This gives us one validation path instead of one validation implementation per transport.

But what about HTTP 400?

This is where another architectural distinction becomes important.

Validation can determine that a command is invalid.

But validation does not necessarily need to know what an HTTP 400 Bad Request is.

These are two different concerns.

The application can produce a semantic application error:

Invalid command

while the HTTP adapter decides how to represent that error:

Invalid command
      ↓
HTTP adapter
      ↓
400 Bad Request

This means the application does not need to depend on HTTP.

Application errors vs HTTP errors

Consider an application error such as:

AppError.badRequest(...)

The name describes the semantic category of the error.

It does not have to mean:

400 Bad Request

inside the application itself.

The HTTP layer can interpret it as:

AppError.badRequest
        ↓
HTTP 400

But another transport could interpret the same application result differently.

For example:

Application
     │
     ▼
AppError.badRequest
     │
     ├── HTTP      → 400
     │
     ├── GraphQL   → GraphQL error
     │
     ├── CLI       → process error
     │
     └── Queue     → message handling result

The important architectural principle is:

The application describes what happened. The transport decides how to represent it.

Validation is not the same as business logic

There is another important distinction.

Validation answers questions such as:

Is quantity an integer?
Is quantity greater than zero?
Is productId present?

These are input validation rules.

The domain may then answer different questions:

Can this order be cancelled?
Is this product available?
Can this state transition happen?

Those are business rules.

A useful flow is therefore:

Command
   │
   ▼
Validation
   │
   ▼
Authorization
   │
   ▼
Handler
   │
   ▼
Domain
   │
   ▼
Infrastructure

Validation checks whether the input can enter the application.

The domain determines whether the requested operation is valid according to the business.

Keeping these concerns separate prevents validation from becoming a second domain layer.

A reusable pipeline

Once validation is treated as application behavior, it becomes possible to compose it with other application-level behaviors.

For example:

Command
   │
   ▼
Validation
   │
   ▼
Authorization
   │
   ▼
Idempotency
   │
   ▼
Logging
   │
   ▼
Handler

This becomes especially useful for commands such as:

CreateOrder
CancelOrder
UpdateProduct
ChangeOrderStatus

Each command can pass through the same application execution model.

The transport no longer needs to orchestrate every cross-cutting concern.

The solution

The general solution is therefore:

Represent the operation as an application command.
Validate the command inside the application execution pipeline.
Return an application-level error when validation fails.
Keep HTTP-specific status codes outside the application.
Let each transport map application errors to its own representation.

Conceptually:

             PRESENTATION
                  │
                  ▼
              HTTP Request
                  │
                  ▼
               Controller
                  │
                  ▼
          CreateOrderCommand
                  │
                  ▼
             APPLICATION
                  │
                  ▼
             Validation
                  │
          ┌───────┴───────┐
          │               │
        valid           invalid
          │               │
          ▼               ▼
       Handler       AppError.badRequest
          │
          ▼
        Domain

And on the way back:

AppError
   │
   ▼
HTTP Adapter
   │
   ▼
HTTP Response

This is the architectural boundary we want.

How Xeno.JS solves this

This is where Xeno.JS comes in.

Xeno.JS already provides an application execution model based around a mediator and pipelines.

Instead of building the validation infrastructure yourself, validation can be implemented as a pipeline behavior.

The conceptual flow becomes:

HTTP
 │
 ▼
Controller
 │
 ▼
Command
 │
 ▼
Xeno Mediator
 │
 ▼
Validation Pipeline
 │
 ▼
Handler

The validation pipeline can use Zod or a custom validation implementation.

For example:

const result = schema.safeParse(command);

if (!result.success) {
  return AppError.badRequest(
    "Invalid order",
    result.error.issues
  );
}

The important part is not Zod itself.

The important part is that the validation happens inside the application execution pipeline.

Xeno does not need to know about HTTP

The validation pipeline does not need to return:

HTTP 400

It returns an application-level result:

AppError.badRequest(...)

The HTTP adapter can then decide:

AppError.badRequest
       ↓
400 Bad Request

This keeps the application independent from the HTTP transport.

The same command can therefore be executed from another entry point without moving the validation logic.

The resulting architecture

With Xeno, the architecture can look like this:

                         HTTP
                          │
                          ▼
                     Controller
                          │
                          ▼
                  CreateOrderCommand
                          │
                          ▼
                  ┌───────────────┐
                  │ Xeno Mediator │
                  └───────┬───────┘
                          │
                          ▼
                 Validation Pipeline
                          │
                    ┌─────┴─────┐
                    │           │
                  valid       invalid
                    │           │
                    ▼           ▼
              Authorization   AppError
                    │
                    ▼
                Idempotency
                    │
                    ▼
                  Handler
                    │
                    ▼
                  Domain
                    │
                    ▼
              Infrastructure
                    │
                    ▼
                PostgreSQL

The important boundary is:

Application
    │
    │ semantic result
    ▼
Presentation
    │
    │ transport representation
    ▼
HTTP

Why this becomes more powerful as the application grows

At first, this distinction might seem unnecessary.

If an application only has:

HTTP → Controller → Service

then validating inside the controller is simple.

But as the application grows:

HTTP
CLI
Workers
Queues
Cron jobs
WebSockets

the value of a transport-independent application layer increases.

All of these entry points can converge on the same application commands:

HTTP ─────┐
CLI ──────┤
Queue ────┼──► Application Command
Worker ───┤           │
Cron ─────┘           ▼
                  Xeno Pipeline
                       │
                  Validation
                       │
                  Authorization
                       │
                    Handler

The application behavior remains consistent.

The adapters remain responsible for their own transport semantics.

The bigger architectural idea

The interesting part is not really validation.

Validation is simply a concrete example of a larger principle:

Application behavior should not depend on the transport that triggered it.

The same principle can be applied to:

authorization
idempotency
logging
request context
caching
retries
transaction handling
other cross-cutting behaviors

The application pipeline becomes the place where these behaviors can be composed around the execution of a use case.

The transport remains responsible for translating external protocols into application commands and translating application results back into protocol-specific responses.

The takeaway

The question is not:

"Should I return HTTP 400 from my validation?"

The better question is:

"Where should the decision that a command is invalid live?"

If that decision belongs to the application, validation can live in the application pipeline.

Then:

Application:
"This command is invalid."

Transport:
"I will represent that as HTTP 400."

Xeno.JS provides this application-level pipeline model natively, allowing validation to be composed into command execution without coupling the application layer to HTTP.

That is the real benefit.

You are not moving HTTP validation somewhere else.

You are moving the application's validation responsibility to the application, while leaving HTTP representation where it belongs: at the HTTP boundary.

Learn more

If you want to go deeper into how Xeno.JS handles application pipelines and validation, you can find the relevant documentation here:

Application Docs

The documentation covers how pipelines fit into the application layer and how validation can be composed with the rest of the application flow.

Want to try Xeno.JS?

Xeno.JS is currently in the adoption phase, and I'm looking for developers who are willing to try it in real projects.

It doesn't have to be a production system or a large application.

A side project, a personal API, an internal experiment, or a small application is more than enough.

If you're interested in trying Xeno.JS, I'd be happy to help you along the way — support is completely free.

The goal at this stage isn't just to get more users. It's to learn from people actually using Xeno.JS:

what feels useful;
what feels confusing;
where the documentation is missing something;
what integrations are needed;
and what should be improved before adopting it in larger projects.

So if you're looking for a TypeScript architecture that keeps the application layer independent from the transport framework, give Xeno.JS a try.

And if something doesn't work the way you expect, let me know.

I'd rather have a few developers actually trying Xeno.JS and giving me honest feedback.

Why I Created Xeno.JS: Architectural Rigor and Zero Infrastructure Constraints

Mattia Carcione — Sat, 03 Oct 2026 18:15:49 +0000

Introduction

How many times have you eagerly started a new TypeScript project, picked the trendy HTTP framework of the month, only to find yourself six months later with a chaotic monolith—hopelessly coupled to a specific library and crushed by unsustainable technical debt?

The problem in modern TypeScript development isn’t writing the first few lines of code. The problem is what happens when the application grows.

The Frustration of Technical Debt and Fragmentation

As business scales, domain logic inevitably ends up blending with infrastructure details. HTTP controllers get bloated with business rules, services depend on monolithic libraries, and dependency injection turns into a tangle of "magical," opaque decorators (reflect-metadata) that make it impossible to understand what’s happening under the hood.

And when requirements change—for instance, if you want to migrate from a traditional Node.js server to a Serverless architecture or Edge Functions to cut down latency—you discover you are chained down: the framework you chose isn't compatible with lightweight V8 Edge engines, forcing you to rewrite your entire application.

The current landscape forces you into a frustrating compromise:

Edge-focused micro-frameworks: You get speed and lightness, but zero architecture—you end up reinventing the wheel to handle validation, CQRS, asynchronous contexts, and clean-code patterns.
Heavy enterprise frameworks: You get structure, but you carry around a rigid, slow infrastructure locked into Node.js.

I ran out of patience having to choose between chaotic freedom and a monolithic prison every single time. So I created Xeno.JS.

Xeno.JS: Architectural Rigor, Zero Infrastructure Constraints

Xeno.JS was born to radically solve this discomfort. It isn’t just another fast HTTP router, but an application architecture framework for TypeScript that combines the rigorous cleanliness and maturity of .NET/C# patterns with the lightness of the modern JavaScript world.

Here is how it solves the problems of technical debt:

° Clean Separation of Boundaries: Xeno.JS strictly separates domain logic and application use cases from infrastructure. By leveraging a system of Commands, Queries, Handlers, and a Mediator with composable pipelines (for validation, performance, and logging), code stays tidy and testable no matter how much the app expands.
° Explicit, Zero-Magic Dependency Injection: No hidden decorators or runtime reflection. Xeno.JS uses a DI container based on explicit factories and strict lifecycles (singleton, scoped, transient) with native checks against circular and captive dependencies.
° Runtime-Agnostic (From Console to the Edge): Because it is designed without heavy Node.js dependencies and without reflection, Xeno.JS is lightweight enough to run seamlessly on command-line apps (CLIs), traditional HTTP servers (Fastify/Node), or natively on Edge Functions (like Cloudflare Workers or Vercel Edge), allowing you to change your deployment target without touching a single line of application logic.
° Plugin/Module Architecture: Thanks to a composable module system via the AppBuilder, you enable only what you need (Database, Redis Cache, Auth, Security pipelines) without weighing down the project with useless dependencies.

Help Me Keep This Vision Alive

I built Xeno.JS because I believe TypeScript deserves a serious, clean, and scalable alternative for those who love solid architecture without sacrificing modernity.

But an Open Source framework doesn’t grow on its own. I need you.

If you share this vision, if you too are tired of easy technical debt and want a tool that respects the longevity of your code:

1- Try Xeno.JS in your next prototypes or projects.
2- Leave a ⭐ on GitHub to give visibility to the project.
3- Test it, open it, report bugs, propose improvements, or discuss new ideas in the community.

The future of clean architecture in TypeScript depends on the feedback and contributions of those who, like you, experience the challenges of software development every day. Try it out and let me know what you think!

Xeno.JS vs NestJS: Different Approaches to TypeScript Application Architecture

Mattia Carcione — Thu, 01 Oct 2026 16:37:34 +0000

Xeno.JS vs NestJS: Different Approaches to TypeScript Application Architecture

If you are building a large TypeScript or Node.js application, you have probably encountered NestJS.

NestJS is a mature backend framework with dependency injection, modules, controllers, middleware, guards, pipes, interceptors, testing utilities, HTTP adapters, microservices, WebSockets, OpenAPI support, and much more.

So why would you need another framework?

The short answer is: Xeno.JS is built around a different architectural boundary.

Your HTTP framework handles HTTP. Xeno.JS handles the application.

Xeno.JS vs NestJS at a glance

Concern	NestJS	Xeno.JS
HTTP	Core part of the backend framework	HTTP infrastructure and adapters without making HTTP the application boundary
HTTP middleware	Middleware, guards, pipes, interceptors	Middleware and HTTP execution infrastructure
CORS	Supported	Supported, including allowed origins and methods
CSRF	Available through integrations/configuration	Built-in CSRF middleware
Cookies	Supported through HTTP integrations	Cookie handling middleware
Authentication	Guards and authentication integrations	Authentication middleware and application authentication infrastructure
Rate limiting	Supported through framework mechanisms and integrations	Rate-limiting middleware
Dependency Injection	Yes	Yes
Modules	Yes	Yes
CQRS	Official CQRS package	Core application execution model
Pipelines	Guards, pipes, interceptors and other framework mechanisms	Application pipelines and behaviors
Request context	Request-scoped providers and execution context	Request context and scopes
Transport independence	Not the primary architectural goal	Core architectural goal
Vue / browser architecture	Not its primary focus	Supported through `@xeno-js/vue`
Application architecture	Integrated into the backend framework	Primary concern

The important difference is therefore not how much HTTP functionality each framework provides.

Xeno.JS provides HTTP infrastructure, middleware, authentication, security-related middleware, rate limiting, cookies, CORS, and adapters.

The architectural distinction is that HTTP is not the boundary that defines the application model.

With Xeno.JS, HTTP can remain one delivery mechanism for an application that is also accessible through workers, CLI commands, queues, scheduled jobs, or other entry points.

The important difference is not the number of features.

It is where the application architecture lives.

What is NestJS?

NestJS is a broad server-side framework for building Node.js applications with TypeScript.

Its architecture provides modules, providers, dependency injection, controllers, middleware, guards, pipes, interceptors, lifecycle mechanisms, testing utilities, and integrations for areas such as HTTP, microservices, WebSockets, OpenAPI, databases, and CQRS.

This makes NestJS a complete environment for building backend applications.

For many projects, that is exactly the model you want.

But there is another way to structure a TypeScript application.

What is Xeno.JS?

Xeno.JS is an application architecture framework for TypeScript.

Instead of making HTTP the center of the application model, Xeno focuses on the layer underneath the transport:

HTTP / Fastify / Hono / Express / CLI / Worker
                         │
                         ▼
                  ┌─────────────┐
                  │   Xeno.JS   │
                  │             │
                  │ Commands    │
                  │ Queries     │
                  │ Pipelines   │
                  │ DI          │
                  │ Context     │
                  │ Modules     │
                  └──────┬──────┘
                         │
                         ▼
                      Domain
                         │
                         ▼
                  Infrastructure

The goal is to keep application logic independent from the mechanism used to deliver a request.

That distinction becomes increasingly useful as a TypeScript application grows beyond a simple HTTP API.

Looking for a NestJS alternative?

If you are looking for a NestJS alternative, Xeno.JS is worth understanding as a different architectural model rather than as a drop-in replacement.

Xeno.JS does not try to reproduce every feature of NestJS.

Instead, it focuses on questions such as:

Where should application logic live?
How should dependencies be composed?
How should commands and queries execute?
Where should validation and authorization happen?
How should request-scoped state be managed?
How can application logic remain independent from HTTP?
How can the same architectural model be used across different entry points?

The distinction can be summarized simply:

NestJS
  └── Broad backend framework

Xeno.JS
  └── Application architecture layer

This does not make one model universally preferable to the other.

They address different architectural concerns.

TypeScript application architecture beyond HTTP

As a TypeScript application grows, HTTP routing is often only one part of the system.

The application may also have:

background workers;
scheduled jobs;
queues;
CLI commands;
event consumers;
internal processes;
browser clients;
multiple external APIs.

If business and application logic are tightly coupled to the HTTP framework, introducing another entry point can become an architectural concern.

Xeno.JS starts from the opposite assumption:

                  ┌───────────┐
                  │   HTTP    │
                  └─────┬─────┘
                        │
                  ┌─────▼─────┐
                  │   Xeno    │
                  └─────┬─────┘
                        │
                  Application
                        │
                     Domain

HTTP is one way into the application.

It does not have to define the application itself.

1. Explicit dependency injection

Both NestJS and Xeno.JS provide dependency injection, but they emphasize different approaches.

Xeno.JS uses explicit programmatic registration.

For example:

const app = new AppBuilder()
  .addServices((services) => {
    services.addScoped('USER_REPOSITORY', (container) => {
      return new UserRepository(
        container.resolve('USER_DATA_SOURCE'),
      )
    })
  })

await app.build()

The dependency graph is visible in the composition code.

There is no requirement for decorator-driven provider discovery or metadata reflection.

This makes dependency registration part of the application's explicit composition root.

For teams that value explicit dependency graphs, this can be an important architectural property.

2. CQRS as part of the application model

NestJS also supports CQRS through its official CQRS package.

The difference is how CQRS fits into the broader architecture.

Xeno.JS treats commands and queries as part of the application execution model.

A command or query can pass through composable application pipelines before reaching its handler:

Command / Query
       │
       ▼
Authorization
       │
       ▼
Validation
       │
       ▼
Idempotency
       │
       ▼
Concurrency
       │
       ▼
Caching / Resilience
       │
       ▼
    Handler

The purpose is to keep cross-cutting application behavior around the execution of a use case rather than repeatedly implementing it inside individual handlers.

CQRS itself is therefore not the differentiator.

Both ecosystems support it.

The architectural difference is how CQRS fits into the application execution model.

3. Application pipelines

Cross-cutting concerns become increasingly important as applications grow.

Validation, authorization, logging, performance monitoring, idempotency, concurrency handling, caching, and resilience can otherwise become scattered throughout application code.

Xeno.JS provides pipelines around commands and queries so these concerns can be composed around application execution.

Conceptually:

Transport
    │
    ▼
Request Context
    │
    ▼
Command / Query
    │
    ▼
Application Pipeline
    │
    ├── Authorization
    ├── Validation
    ├── Idempotency
    ├── Concurrency
    ├── Caching
    └── Resilience
    │
    ▼
Handler
    │
    ▼
Domain / Infrastructure

This gives the application a defined execution boundary.

4. The transport is not the application

A typical Xeno.JS application can keep its HTTP layer outside the application architecture.

For example, Fastify can remain responsible for HTTP:

fastify.get('/users/:id', async (request, reply) => {
  // Translate HTTP into an application operation.
})

The application operation can then be represented independently:

HTTP request
     │
     ▼
Transport adapter
     │
     ▼
Command / Query
     │
     ▼
Xeno pipeline
     │
     ▼
Application handler
     │
     ▼
Domain / Infrastructure

Xeno.JS provides integrations for environments such as Fastify and Vercel while keeping its architectural focus on the application layer.

The point is not that Xeno replaces Fastify.

The point is that Fastify and Xeno can have different responsibilities.

Use the HTTP framework for HTTP.

Use the application architecture for the application.

5. Application context and scopes

Large applications often need more than singleton services.

A request may have its own:

identity;
tenant information;
transaction;
scoped dependencies;
request metadata;
tracing information.

Xeno.JS provides explicit service lifetimes and request context using asynchronous execution context.

This allows request-specific state and scoped services to follow the execution boundary without requiring every method to receive request state explicitly.

The architectural model becomes:

Request
   │
   ▼
Request Context
   │
   ├── Identity
   ├── Scoped Services
   ├── Transaction
   └── Request Metadata
   │
   ▼
Application Execution

This is particularly relevant for applications where execution context needs to cross multiple application and infrastructure boundaries.

Do you need to replace NestJS?

Not necessarily.

If NestJS already provides everything your application needs, there may be no reason to replace it.

Xeno.JS is not designed as a drop-in replacement for every capability provided by NestJS.

It is more relevant when you want the application layer itself to have an explicit architecture independent from the HTTP framework.

For example:

                  ┌───────────┐
                  │  Fastify  │
                  └─────┬─────┘
                        │
                  ┌─────▼─────┐
                  │   Xeno    │
                  └─────┬─────┘
                        │
                   Application
                        │
                     Domain

The same architectural idea can be used with different entry points:

Fastify ───────┐
               │
CLI ───────────┤
               ├──► Xeno.JS ──► Application ──► Domain
Worker ────────┤
               │
Queue ─────────┘

The HTTP layer becomes one delivery mechanism rather than the architectural center of the application.

Xeno.JS is not trying to be another NestJS

Xeno.JS already provides infrastructure integrations, HTTP adapters, authentication, databases, caching, resilience, logging, a CLI, and Vue integration.

But its architectural center is different.

The goal is not to reproduce every capability of a mature backend framework.

The goal is to provide a consistent application architecture for TypeScript:

Presentation
     │
     ▼
Application
     │
     ├── Commands
     ├── Queries
     ├── Handlers
     ├── Pipelines
     ├── Context
     └── Dependency Injection
     │
     ▼
Domain
     │
     ▼
Infrastructure

This also means Xeno.JS can coexist with technologies that already do their jobs well.

Use Fastify for HTTP.

Use Hono for edge-oriented HTTP applications.

Use Vue for the UI.

Use Drizzle for database access.

Use Redis for distributed caching.

Use the transport and infrastructure tools that fit your system.

Xeno.JS provides the application architecture connecting these pieces.

When should you consider Xeno.JS?

Xeno.JS becomes particularly relevant when:

your TypeScript application is becoming large;
domain logic is becoming mixed with infrastructure code;
dependency graphs are becoming difficult to understand;
you want explicit dependency injection;
you want CQRS as an application model;
cross-cutting behavior is growing around your use cases;
you have multiple entry points such as HTTP, workers, CLI, or queues;
you want the application layer to remain independent from the transport;
you want a consistent architectural model across backend and frontend.

It is not necessary for every TypeScript project.

A small CRUD API may not need an application architecture framework.

But as the system grows, architecture becomes less about choosing a router and more about deciding where business logic, dependencies, execution context, and infrastructure boundaries live.

That is the problem Xeno.JS is designed to solve.

Conclusion

NestJS and Xeno.JS should not necessarily be viewed as direct replacements for each other.

NestJS is a mature, broad backend framework.

Xeno.JS is an application architecture framework focused on explicit dependency injection, CQRS, pipelines, request context, domain boundaries, and transport independence.

The key difference is the architectural boundary:

NestJS
  └── Broad backend framework

Xeno.JS
  └── Application architecture layer

If you already have a framework that handles HTTP well, you do not necessarily need to replace it.

You can keep it.

Xeno.JS is designed to structure what happens after your transport enters the application.

Learn more about Xeno.JS

Explore Xeno.JS on GitHub