0Pricing
tRPC End-to-End Type Safe APIs · レッスン

カスタムミドルウェアチェーン

ロギング、レート制限、認可などのカスタムミドルウェアを構築し、それらを連鎖させます。

「カスタムミドルウェアチェーン」はCoddyKit上の無料tRPC End-to-End Type Safe APIsレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはtRPC End-to-End Type Safe APIs学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 tRPC End-to-End Type Safe APIsコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

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:

  1. logMiddleware runs first.
  2. If logMiddleware calls next(), then isAuthenticated runs.
  3. If isAuthenticated calls next(), then the actual query procedure handler runs.
  4. 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!

よくある質問

「カスタムミドルウェアチェーン」レッスンは無料ですか？

はい。「カスタムミドルウェアチェーン」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、tRPC End-to-End Type Safe APIsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 tRPC End-to-End Type Safe APIsコースには全4レッスンが含まれています。

「カスタムミドルウェアチェーン」で何を学びますか？

ロギング、レート制限、認可などのカスタムミドルウェアを構築し、それらを連鎖させます。 ブラウザで直接実行するハンズオンコードでtRPC End-to-End Type Safe APIsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

tRPC End-to-End Type Safe APIsを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのtRPC End-to-End Type Safe APIsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。

「カスタムミドルウェアチェーン」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このtRPC End-to-End Type Safe APIsレッスンでコードを書いて実行できますか？

はい。すべてのtRPC End-to-End Type Safe APIsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. tRPCコンテキストの作成
  2. 認証ミドルウェア
  3. カスタムミドルウェアチェーン
  4. ロギングとパフォーマンス計測ミドルウェア
← tRPC End-to-End Type Safe APIsに戻る