Cadenas de middleware personalizadas
Cree middleware personalizado para registro, limitación de solicitudes o autorización, y encadénelos.
Cadenas de middleware personalizadas es una lección gratuita de tRPC End-to-End Type Safe APIs en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de tRPC End-to-End Type Safe APIs, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de tRPC End-to-End Type Safe APIs incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
Chain Multiple Middleware
In tRPC, middleware lets you run logic before your procedure executes. What if you need multiple checks, like logging, authentication, and validation, for a single API call?
This is where middleware chains come in handy! They allow you to stack multiple middleware functions, executing them one after another.
Benefits of Chaining
Chaining middleware offers several advantages:
- Modularity: Each middleware focuses on a single responsibility (e.g., logging, auth).
- Reusability: Create generic middleware that can be applied to different procedures or routers.
- Order of Execution: Control the exact sequence of operations before your main procedure logic runs.
- Early Exit: A middleware can stop the chain early if a condition isn't met (e.g., unauthorized access).
How `next()` Works
Recall that tRPC middleware receives a next function. Calling next() passes control to the next middleware in the chain, or to the actual procedure handler if it's the last middleware.
If a middleware doesn't call next(), the chain stops, and the procedure handler will not execute. This is crucial for checks like authentication!
First: Logging Middleware
Let's create a simple logging middleware. It will log when a request starts and how long it took. This is a common pattern for monitoring.
Notice how next() is awaited to ensure the procedure (and subsequent middleware) completes before logging the duration.
type Context = { userId: string | null };
const trpc = {
middleware: (handler: any) => handler,
procedure: {
use: (mw: any) => ({
query: (f: any) => f,
mutation: (f: any) => f
}),
query: (f: any) => f,
mutation: (f: any) => f
},
router: (cfg: any) => cfg,
};
const logMiddleware = trpc.middleware(async ({ path, type, next }) => {
console.log(`[${type}] Request to ${path} started.`);
const start = Date.now();
const result = await next();
const durationMs = Date.now() - start;
console.log(`[${type}] Request to ${path} finished in ${durationMs}ms.`);
return result;
});
const appRouter = trpc.router({
example: trpc.procedure
.use(logMiddleware)
.query(() => "Data fetched!")
});Second: Auth Middleware
Next, we'll build an authentication middleware. This middleware will check if a user is logged in (i.e., if ctx.userId exists). If not, it will throw an error, effectively stopping the procedure.
Remember, the ctx (context) object is passed to middleware, allowing access to request-specific data.
type Context = { userId: string | null };
const trpc = {
middleware: (handler: any) => handler,
procedure: {
use: (mw: any) => ({
query: (f: any) => f,
mutation: (f: any) => f
}),
query: (f: any) => f,
mutation: (f: any) => f
},
router: (cfg: any) => cfg,
};
const isAuthenticated = trpc.middleware(async ({ ctx, next }) => {
if (!ctx.userId) {
throw new Error("UNAUTHORIZED: Please log in.");
}
return next();
});
const appRouter = trpc.router({
protected: trpc.procedure
.use(isAuthenticated)
.query(({ ctx }) => `Welcome, user ${ctx.userId}!`)
});Building a Middleware Chain
Now, let's combine our logMiddleware and isAuthenticated middleware. The order matters: logging should happen first, then authentication.
We simply use .use() multiple times. tRPC will execute them in the order they are defined.
type Context = { userId: string | null };
const trpc = {
middleware: (handler: any) => handler,
procedure: {
use: (mw: any) => ({
query: (f: any) => f,
mutation: (f: any) => f
}),
query: (f: any) => f,
mutation: (f: any) => f
},
router: (cfg: any) => cfg,
};
const logMiddleware = trpc.middleware(async ({ path, type, next }) => {
console.log(`[${type}] Request to ${path} started.`);
const start = Date.now();
const result = await next();
const durationMs = Date.now() - start;
console.log(`[${type}] Request to ${path} finished in ${durationMs}ms.`);
return result;
});
const isAuthenticated = trpc.middleware(async ({ ctx, next }) => {
if (!ctx.userId) {
throw new Error("UNAUTHORIZED: Please log in.");
}
return next();
});
const appRouter = trpc.router({
protectedData: trpc.procedure
.use(logMiddleware)
.use(isAuthenticated)
.query(({ ctx }) => `Secret data for ${ctx.userId}!`)
});Order of Execution
When a request hits protectedData:
logMiddlewareruns first.- If
logMiddlewarecallsnext(), thenisAuthenticatedruns. - If
isAuthenticatedcallsnext(), then the actualqueryprocedure handler runs. - If any middleware throws an error (like
isAuthenticated), the chain stops immediately, and the error is returned.
Dynamic Middleware
What if you need different authorization levels? You can create a function that returns a middleware, allowing for dynamic configuration.
This pattern is called a middleware builder and is powerful for creating flexible and reusable middleware.
type Context = { userId: string | null; userRole: string | null };
const trpc = {
middleware: (handler: any) => handler,
procedure: {
use: (mw: any) => ({
query: (f: any) => f,
mutation: (f: any) => f
}),
query: (f: any) => f,
mutation: (f: any) => f
},
router: (cfg: any) => cfg,
};
const hasRole = (requiredRole: string) => {
return trpc.middleware(async ({ ctx, next }) => {
if (!ctx.userRole || ctx.userRole !== requiredRole) {
throw new Error(`FORBIDDEN: ${requiredRole} role required.`);
}
return next();
});
};
const appRouter = trpc.router({
adminPanel: trpc.procedure
.use(hasRole("admin"))
.query(() => "Welcome, admin!")
});Chaining Dynamic Middleware
You can mix and match static middleware (like our logger) with dynamic middleware builders (like our role checker) in the same chain.
This allows for highly flexible and secure API endpoints, where specific logic can be applied based on configuration or runtime values.
type Context = { userId: string | null; userRole: string | null };
const trpc = {
middleware: (handler: any) => handler,
procedure: {
use: (mw: any) => ({
query: (f: any) => f,
mutation: (f: any) => f
}),
query: (f: any) => f,
mutation: (f: any) => f
},
router: (cfg: any) => cfg,
};
const logMiddleware = trpc.middleware(async ({ path, type, next }) => {
console.log(`[${type}] Request to ${path} started.`);
const start = Date.now();
const result = await next();
const durationMs = Date.now() - start;
console.log(`[${type}] Request to ${path} finished in ${durationMs}ms.`);
return result;
});
const hasRole = (requiredRole: string) => {
return trpc.middleware(async ({ ctx, next }) => {
if (!ctx.userRole || ctx.userRole !== requiredRole) {
throw new Error(`FORBIDDEN: ${requiredRole} role required.`);
}
return next();
});
};
const appRouter = trpc.router({
adminReport: trpc.procedure
.use(logMiddleware)
.use(hasRole("admin"))
.query(() => "Sensitive admin report data.")
});Middleware Chain Logic
Consider the following tRPC procedure definition:
// Assume logMiddleware and authMiddleware are defined
// authMiddleware throws if ctx.userId is null
// logMiddleware always calls next()
const myProcedure = trpc.procedure
.use(logMiddleware)
.use(authMiddleware)
.query(({ ctx }) => `Hello ${ctx.userId}`);If a request comes in with ctx.userId = null, what will happen?
Chains Recap
Great job! You've learned how to build and chain multiple custom middleware in tRPC.
- Middleware chains allow you to apply multiple layers of logic (logging, authentication, validation) before a procedure executes.
- The
.use()method is used to add middleware, and they run in the order they are defined. - The
next()function is key to passing control down the chain. - Middleware builders can create dynamic, configurable middleware for enhanced reusability.
This powerful pattern helps keep your tRPC API code clean, modular, and robust!
Preguntas frecuentes
¿La lección «Cadenas de middleware personalizadas» es gratis?
Sí — el texto completo de «Cadenas de middleware personalizadas» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de tRPC End-to-End Type Safe APIs, actualiza a CoddyKit PRO. El curso de tRPC End-to-End Type Safe APIs incluye 4 lecciones en total.
¿Qué aprenderé en «Cadenas de middleware personalizadas»?
Cree middleware personalizado para registro, limitación de solicitudes o autorización, y encadénelos. Practicas tRPC End-to-End Type Safe APIs con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar tRPC End-to-End Type Safe APIs?
No se requiere experiencia previa. tRPC End-to-End Type Safe APIs en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.
¿Cuánto tiempo toma la lección «Cadenas de middleware personalizadas»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de tRPC End-to-End Type Safe APIs?
Sí. Cada lección de tRPC End-to-End Type Safe APIs incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Creación del contexto de tRPC
- Middleware de autenticación
- Cadenas de middleware personalizadas
- Middleware de registro y medición del rendimiento