Middleware patterns in Deno

Introduction

Middleware helps your app handle tasks step-by-step, like checking users or logging info, before doing the main work.

You want to check if a user is logged in before showing a page.

You need to log every request to see what users do.

You want to add headers to responses for security.

You want to handle errors in one place for all requests.

You want to parse incoming data like JSON before using it.

Syntax

Deno

async function middleware(ctx, next) {
  // Do something before
  await next();
  // Do something after
}

ctx is the context of the request and response.

next() calls the next middleware in the chain.

Examples

This middleware logs request and response info around the main handler.

Deno

async function logger(ctx, next) {
  console.log(`Request: ${ctx.request.method} ${ctx.request.url}`);
  await next();
  console.log(`Response status: ${ctx.response.status}`);
}

This middleware checks for an Authorization header and stops if missing.

Deno

async function auth(ctx, next) {
  if (!ctx.request.headers.get('Authorization')) {
    ctx.response.status = 401;
    ctx.response.body = 'Unauthorized';
    return;
  }
  await next();
}

Sample Program

This Deno Oak app uses middleware to log requests, check authorization, and then respond. If no Authorization header is sent, it replies with 401 Unauthorized. Otherwise, it says hello.

Deno

import { Application } from "https://deno.land/x/oak@v12.5.0/mod.ts";

const app = new Application();

// Logger middleware
app.use(async (ctx, next) => {
  console.log(`Request: ${ctx.request.method} ${ctx.request.url}`);
  await next();
  console.log(`Response status: ${ctx.response.status}`);
});

// Simple auth middleware
app.use(async (ctx, next) => {
  if (!ctx.request.headers.get('Authorization')) {
    ctx.response.status = 401;
    ctx.response.body = 'Unauthorized';
    return;
  }
  await next();
});

// Main response
app.use((ctx) => {
  ctx.response.body = 'Hello, authorized user!';
});

console.log('Server running on http://localhost:8000');
await app.listen({ port: 8000 });

Important Notes

Always call await next() to continue to the next middleware unless you want to stop the chain.

Order matters: middleware runs in the order you add it.

Middleware can do work before and after next(), like logging or modifying responses.

Summary

Middleware runs code step-by-step for each request.

Use ctx to access request and response info.

Call await next() to move to the next middleware.

Practice

1. What is the main purpose of middleware in a Deno web application?

easy

A. To compile TypeScript code into JavaScript

B. To store data permanently in a database

C. To run code step-by-step for each incoming request

D. To create user interface components

Solution

1. Step 1: Understand middleware role

   Middleware processes each request in order, allowing code to run before sending a response.

2. Step 2: Compare options

   Only To run code step-by-step for each incoming request describes this step-by-step request handling. Other options describe unrelated tasks.

3. Final Answer:

   To run code step-by-step for each incoming request -> Option C

4. Quick Check:

   Middleware = step-by-step request code [OK]

Hint: Middleware runs code for each request in order [OK]

Common Mistakes:

• Confusing middleware with database operations
• Thinking middleware builds UI components
• Assuming middleware compiles code

2. Which of the following is the correct way to call the next middleware in Deno?

easy

A. next.await()

B. next()

C. call next()

D. await next()

Solution

1. Step 1: Recall async middleware pattern

   Middleware functions are async and must await next() to continue the chain.

2. Step 2: Check syntax correctness

   Only 'await next()' correctly waits for the next middleware to finish before continuing.

3. Final Answer:

   await next() -> Option D

4. Quick Check:

   Use await next() to proceed [OK]

Hint: Always use await before next() in async middleware [OK]

Common Mistakes:

• Calling next() without await causing unexpected behavior
• Using incorrect syntax like call next()
• Trying to use next.await() which is invalid

3. Given this middleware code snippet in Deno:

async function logger(ctx, next) {
  console.log('Before');
  await next();
  console.log('After');
}

async function handler(ctx) {
  ctx.response.body = 'Hello';
}

// Middleware chain: logger -> handler

What will be printed to the console when a request is handled?

medium

A. Before\nAfter

B. After\nBefore

C. Before

D. After

Solution

1. Step 1: Analyze middleware flow

   Logger prints 'Before', then awaits next middleware (handler), then prints 'After'.

2. Step 2: Understand order of prints

   Since handler runs between the two console.logs, output order is 'Before' then 'After'.

3. Final Answer:

   Before\nAfter -> Option A

4. Quick Check:

   Middleware logs before and after next() [OK]

Hint: Middleware logs before and after await next() [OK]

Common Mistakes:

• Assuming 'After' prints before 'Before'
• Thinking only 'Before' or 'After' prints
• Ignoring await causing wrong order

4. Identify the error in this Deno middleware code:

async function auth(ctx, next) {
  if (!ctx.request.headers.get('Authorization')) {
    ctx.response.status = 401;
    ctx.response.body = 'Unauthorized';
  }
  await next();
}

medium

A. Missing await before ctx.request.headers.get

B. Should return after setting 401 to stop middleware chain

C. ctx.response.body must be a JSON object

D. next() should not be awaited

Solution

1. Step 1: Understand middleware flow control

   If authorization header is missing, response is set to 401, but code still calls await next(), continuing the chain.

2. Step 2: Identify fix to stop chain

   To prevent further middleware running, function should return immediately after setting 401 response.

3. Final Answer:

   Should return after setting 401 to stop middleware chain -> Option B

4. Quick Check:

   Return early to stop middleware chain [OK]

Hint: Return after response to stop middleware chain [OK]

Common Mistakes:

• Not returning causes next middleware to run anyway
• Thinking await is missing on header get
• Believing response body must be JSON always

5. You want to create a middleware in Deno that measures how long each request takes and adds a custom header X-Response-Time with the duration in milliseconds. Which of the following middleware implementations correctly achieves this?

hard

A. async function responseTime(ctx, next) {
const start = performance.now();
await next();
const ms = performance.now() - start;
ctx.response.headers.set('X-Response-Time', ms.toFixed(2));
}

B. async function responseTime(ctx, next) {
const start = Date.now();
const ms = Date.now() - start;
ctx.response.headers.set('X-Response-Time', `${ms}ms`);
await next();
}

C. async function responseTime(ctx, next) {
const start = Date.now();
next();
const ms = Date.now() - start;
ctx.response.headers.set('X-Response-Time', `${ms}ms`);
}

D. async function responseTime(ctx, next) {
await next();
const ms = Date.now();
ctx.response.headers.set('X-Response-Time', ms);
}

Solution

1. Step 1: Measure time before and after next()

   Start timer before await next(), then calculate duration after it finishes.

2. Step 2: Use precise timer and set header correctly

   performance.now() gives better precision than Date.now(). Setting header with ms.toFixed(2) formats nicely.

3. Final Answer:

   Middleware using performance.now(), await next(), and setting header after next() -> Option A

4. Quick Check:

   Use performance.now() and await next() then set header [OK]

Hint: Start timer before await next(), set header after [OK]

Common Mistakes:

• Calculating time before await next() runs
• Using Date.now() which is less precise
• Setting header before next() completes