![Coffee Filter - Selective Filtering](/images/selective-redeployments-cloud-functions/hero.png)

[Firebase Functions](https://firebase.google.com/docs/functions) are a convenient wrapper around [Google Cloud Functions](https://cloud.google.com/functions).

My team at [upcover](https://upcover.com) started using them to prototype and deploy APIs on Google Cloud.
They provide an easy local development experience with the [Firebase Emulator Suite](https://firebase.google.com/docs/emulator-suite), and a convenient deployment workflow with the `firebase` CLI.

## Issues

As our product grew in complexity, the number of Cloud Functions we maintained increased significantly. Once we hit around 60 Cloud Functions, we experienced two major issues:

1. The `firebase` CLI tries to deploy all Cloud Functions in your project in parallel. Given enough Cloud Functions, it leads to rate limit errors with the Google Cloud API.
2. The CLI deploys every Cloud Function every time, regardless of whether a function actually needs redeployment.

## Solving Rate Limit Errors

Google Cloud has [well defined quotas](https://firebase.google.com/docs/functions/quotas) for API calls. The `firebase deploy` command frequently exceeded this quota,
because it tried to deploy every Cloud Function in parallel.

To solve the API rate limit problem, we started deploying our Cloud Functions in batches of 30. I created a simple Node.js script that did the following:

1. Discover all Cloud Functions exported from the repository.
2. Partition discovered functions into batches of 30 (I settled on the number 30 arbitrarily).
3. Run the `firebase deploy --only functions:[<function-names>]` for the functions in each batch.

Here's a simplified implementation of the script:

```ts
import { chunk } from "lodash";
import { execSync } from "child_process";

const functionsIndex = require("./libs/src/index");
const exportedFunctions = Object.keys(functionsIndex);

const batches = chunk(exportedFunctions, 30);

for (const batch of batches) {
 const args = batch
 .map((functionName) => `function:${functionName}`)
 .join(",");

 const command = `firebase deploy --only ${args}`;
 execSync(command, { stdio: "inherit" });
}
```

The `functionsIndex` module is a compiled JavaScript file. It's produced from the `src/index.ts` TypeScript file containing all exported Cloud Functions.
Here's a sample of what it looks like:

```ts
// src/index.ts

export { auth } from "./services/auth/function";
export { quotes } from "./services/quotes/function";
export { documents } from "./services/documents/function";
```

**This script solved the rate limit errors, but led to longer CI builds**.

It ran `firebase deploy` multiple times: once for every batch of Cloud Functions. While this led to longer builds, it was needed because the deployments outright failed otherwise.

### Adopting Selective Redeployments

Every Cloud Function requires time to deploy. The more Cloud Functons you have, the longer your deployment time.
When our CI build hit a duration of 30 mins, we began investigating possible solutions.

Our CTO, Sajjad Naveed, pointed out that we could reduce the time by deploying only the Cloud Functions that changed.
To detect changed Cloud Functions, he suggested a way to calculate every function's identity.

**If the identity of a function does not change, it does not need redeployment.**

### Cloud Function Identity

Sajjad suggested bundling a Cloud Function, and then calculating a hash of the bundle to produce the its identity.

I created a script that performed the following steps:

1. Discover every Cloud Function in the repository.
2. Bundle the code of every Cloud Function using a bundler, with minification and tree shaking.
3. Calculate the hash of the bundled code.
4. Compare the newly calculated hash with an existing hash value stored in a local file. If unchanged, append the function to the list of functions that need redeployment. Finally, update the local file containing hashes with the new hash of this function.
5. Selectively deploy only the functions that need redeployment.

### Why Does This Work?

Consider the following Cloud Function:

```ts
import * as functions from "firebase-functions";
import { FooService } from "./fooService";

export const FooFunction = functions.https.onRequest((req, res) => {
 const message = FooService.getMessage();
 res.json({ message });
});
```

The identity of `FooFunction` can change due to three reasons only:

1. If we update the `firebase-functions` package
2. If we update the implementation of `FooService`
3. If `FooFunction` itself changes (if we change the response to `res.status(201).json({ message })`)

**Simply put, the identity of a Cloud Function changes only its code, or its dependencies change**

Bundling therefore works great for this purpose: the produced bundle for a Cloud Function would change when any/all of the above happen.
A different bundle would produce a different hash, and therefore, a new identity.

## Results

Selective redeployments dramatically reduced our **average** deployment time.

If a pull request affected only a single cloud function, merging that pull request would trigger redployment of that function only.
However, if a pull request updated a dependency used by many cloud functions, all of them would need redeployment.

Here are some screenshots to demonstrate:

![Short Selective Redeployment](/images/selective-redeployments-cloud-functions/short-selective-redployment.png)


 Deployment Affecting a Single Cloud Function


![Long Selective Redeployment](/images/selective-redeployments-cloud-functions/long-selective-redeployment.png)


 Deployment Affecting Multiple Cloud Functions


I used [ESBuild](https://esbuild.github.io) as the bundler (mainly due to its speed), but the process should work with any bundler.

## functions-differ

I decided to build this functionality into a reusable open source package.

Meet [`functions-differ`](https://npmjs.com/package/functions-differ). A CLI tool written in Node.js that calculates and maintains function identities. Use it to selectively redeploy your Cloud Functions.

It's an experimental tool that I maintain in my free time, so there are some rough edges. Feel free to try it and share feedback.

I plan to write a post on how to integrate `functions-differ` with your CI workflow in the future. Watch this space for more.

---

_Thanks to [Bhanu](https://github.com/hiiambhanu) and Sajjad for contributing to this tool._

_Questions, comments, or feedback? Reach out to me on Twitter: [@haroldadmin](https://twitter.com/haroldadmin)_

Selective redeployment of Cloud Functions for faster CI builds

Optimizing Deployments for Cloud Functions



![Hero Image](/images/cloudflare-jitpack-shields/hero.png)

I have published a few libraries on [Jitpack](https://jitpack.io).

I like Jitpack for its simplicity. Besides artifact hosting, it offers [release badges](https://jitpack.io/docs/#badges), and a free, public [API](https://docs.jitpack.io/api) to query statistics about published libraries. One such stat is the number of weekly and monthly [downloads](https://docs.jitpack.io/api/#download-statistics).

**I wanted to display the number of downloads as a badge on one of my library's README file**, but Jitpack does not offer badges for download statistics.

Given the lack of official support, I started looking for alternatives and discovered [Shields.io](https://shields.io/), a platform that offers many different types of badges for free. Unfortunately, it does not have badges for Jitpack download stats either.
It does have the ability to build badges from custom API [endpoints](https://shields.io/endpoint), as long as the API responds with a fixed predefined schema.

---

**Shields.io Schema**

| Property        | Description                                                                                                                                                                                                                                                                                                                                 |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `schemaVersion` | _Required_. Always the number 1.                                                                                                                                                                                                                                                                                                            |
| `label`         | _Required_. The left text, or the empty string to omit the left side of the badge. This can be overridden by the query string.                                                                                                                                                                                                              |
| `message`       | _Required_. Can't be empty. The right text.                                                                                                                                                                                                                                                                                                 |
| `color`         | _Default: lightgrey_. The right color. Supports the eight named colors above, as well as hex, rgb, rgba, hsl, hsla and css named colors. This can be overridden by the query string.                                                                                                                                                        |
| `cacheSeconds`  | _Default: 300_, min 300. Set the HTTP cache lifetime in seconds, which should be respected by the Shields' CDN and downstream users. Values below 300 will be ignored. This lets you tune performance and traffic vs. responsiveness. The value you specify can be overridden by the user via the query string, but only to a longer value. |

---

Here's what the response of Jitpack's download stats API looks like:

```json
{
  "week": 1707,
  "month": 22214
}
```

To create my badge, I needed to build a service that acts as an adapter between Jitpack and Shield.io.

![Flow](/images/cloudflare-jitpack-shields/flow.svg)

A serverless function felt like the natural fit for this task. I could use one of a number of available options:

- HTTPS Google Cloud Function
- Containerised Google Cloud Run service
- AWS Lambda

I decided I wanted to learn something new, so I went with a [Cloudflare Worker](https://workers.cloudflare.com/) instead.

Cloudflare offers a generous free tier, but I was surprised to learn about the 50ms CPU time limit on a worker.
Even if Jitpack's API was extremely fast, it would surely take more than 50ms to fetch download stats for an artifact.

After reading some docs, I realized the time limit is for **active CPU usage only**. Most of my worker's time would be spent awaiting a `fetch()` API call, and thankfully that won't count as active CPU time.

Cloudflare's quickstart guide was enough to teach me everything I needed to build the worker. Ignoring all the setup with the `wrangler` CLI, here's what the worker looks like:

```javascript
const baseUrl = "https://jitpack.io/api";

addEventListener("fetch", (event) => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const url = new URL(request.url);

  const group = url.searchParams.get("group");
  const artifact = url.searchParams.get("artifact");
  const frequency = url.searchParams.get("frequency");

  let res;
  switch (frequency) {
    case "monthly":
      res = await getMonthlyDownloads(group, artifact);
      break;
    case "weekly":
      res = await getWeeklyDownloads(group, artifact);
      break;
    default:
      return new Response(null, { status: 400 });
  }

  return new Response(JSON.stringify(res), {
    headers: { "content-type": "application/json" },
  });
}

async function getMonthlyDownloads(groupId, artifactId) {
  const downloadsUrl = `${baseUrl}/downloads/${groupId}/${artifactId}`;
  const response = await fetch(downloadsUrl);
  const { month: monthlyDownloads } = await response.json();

  const res = {
    schemaVersion: 1,
    label: "Downloads",
    message: `${monthlyDownloads}/month`,
    color: "green",
  };

  return res;
}

async function getWeeklyDownloads(groupId, artifactId) {
  const downloadsUrl = `${baseUrl}/downloads/${groupId}/${artifactId}`;
  const response = await fetch(downloadsUrl);
  const { week: weeklyDownloads } = await response.json();

  const res = {
    schemaVersion: 1,
    label: "Downloads",
    message: `${weeklyDownloads}/week`,
    color: "green",
  };

  return res;
}
```

I then deployed it with `wrangler publish`, and then created a custom shield on Shields.io.

The result: ![Result](/images/cloudflare-jitpack-shields/result.png)

I'm pretty happy with how it turned out. This was my first experience with Cloudflare Workers, and it left a positive impression. I might start using it more in the near future.

---

_Question, comments or feedback? Feel free to reach out to me on Twitter [@haroldadmin](https://twitter.com/haroldadmin)_


Creating a Shields.io badge for Jitpack downloads using Cloudflare Workers

Experiments with Cloudflare Workers



![Hero Image](/images/joi-data-transformation/hero.png)

The Node.js community has access to many data validation libraries like [Ajv](https://www.npmjs.com/package/ajv), [Yup](https://www.npmjs.com/package/yup), [class-validator](https://www.npmjs.com/package/class-validator), [validate.js](https://www.npmjs.com/package/validate.js), and more. One library that stands out to me is [Joi](https://www.npmjs.com/package/joi).

Joi is popular, battle tested, and very powerful, but it's often mistaken to be "just" a data validation library even though it can also transform data. This ability is really useful when building REST APIs, as I'll demonstrate using a combination of Nest.js and Joi.

Consider the following Nest.js `Pipe` that validates an incoming request body using a Joi schema:

```ts
import { Schema } from "joi";
import { PipeTransform, BadRequestException } from "@nestjs/common";

class SchemaValidator implements PipeTransform {
  constructor(readonly schema: Schema) {}

  transform(incoming: unknown): unknown {
    const { error } = this.schema.validate(incoming);
    if (error) {
      throw new BadRequestException(error.message);
    }

    return incoming;
  }
}

// Convenient way to apply the SchemaValidator
function useSchema(schema: Schema): SchemaValidator {
  return new SchemaValidator(schema);
}
```

It runs the incoming value through the given schema to validate it. It then returns a "400 Bad Request" response if the validation is unsuccessful, or returns the value as-is otherwise. You can apply it as any other pipe:

```ts
@Controller()
class UserController {
  @Get("/:email/picture")
  getProfilePicture(
    @Param("email", useSchema(Joi.string().email().required()))
    email: string
  ): string {
    // ...
  }
}
```

A common practice when working with emails is to lowercase them before usage. The simplest way to do this would be to call `email.toLowerCase()` in the controller method, but you could also leverage Joi's capabilities for this.

First, apply the `lowercase` transformation to the schema:

```ts
@Get("/:email/picture)
getProfilePicture(
  @Param("email", withSchema(Joi.string().email().lowercase().required()))
	email: string
)
```

Then adjust the `transform` method of `SchemaValidator` pipe to return Joi's validated value instead of the original value:

```ts
transform(incoming: unknown): unknown {
  const { error, value } = this.schema.validate(incoming);
	if (error) {
		throw new BadRequestException(error.message);
	}

  return value;
}
```

This ensures that the value returned from this pipe will be lowercase as long as the `convert` option is enabled (it's enabled by default). You can use any of the other available transformations like `default()`, `sort()`, `binary()` when needed, and you could also apply custom transformations using your own functions.

It's a best practice to normalize emails before usage. `foo@gmail.com` and `foo+bar@gmail.com` are the same email addresses from Gmail's perspective. Similarly, `foobar@gmail.com` and `foo.bar@gmail.com` point to the same email. It's therefore important to normalize email variants before use through a package like [normalize-email](https://www.npmjs.com/package/normalize-email).

First, write a custom validator for your email schema that uses the `normalize-email` package:

```ts
import { CustomHelpers, ErrorReport } from "joi";
import normalize from "normalize-email";

function normalizeEmail(
  value: string | undefined,
  helpers: CustomHelpers
): string | ErrorReport {
  try {
    const normalized = normalize(value);
    return normalized;
  } catch (error) {
    return helpers.message({ custom: "Failed to normalize email" });
  }
}
```

Then modify your controller to use it:

```ts
@Get("/:email/picture)
getProfilePicture(
  @Param("email", withSchema(Joi.string().email().lowercase().required().custom(normalizeEmail)))
	email: string
)
```

And now you will always received normalized emails!

---

If you liked this post and want more content on Joi, let me know with a tweet [@haroldadmin](https://twitter.com/haroldadmin)!


Joi for Data Transformations

![Hero](/images/asynclocalstorage-logs-nestjs/hero.png)

Logging is invaluable in backend services. Structured logging makes logs more useful by enabling you to categorize, analyze and search logs effectively. Sadly though, setting up structured logging correctly is difficult, especially in dependency injection-oriented frameworks such as [Nest.js](https://nestjs.com/).

This blog post is code-snippet heavy. It's the most succinct way to convey the problem I'm trying to solve, so prepare to read a lot of code.

Consider the following `AuthService` that validates a user's credentials and logs information using a hypothetical `StructuredLogger`:

```typescript
@Injectable()
class AuthService {
 constructor(
 private readonly logger: StructuredLogger,
 private readonly auth0: Auth0Service
 ) {}

 validate = async (creds: Credentials): Promise<string | Error> => {
 this.logger.info({ ...creds }, "Validating credentials");

 const result = await checkCredentials(creds);
 if (!result.success) {
 this.logger.error({ error: result.error }, "Invalid credentials");
 return result.error;
 }

 this.logger.info("Credentials valid");
 return result.accessToken;
 };
}
```

The `validate` method produces the following log statment whenever it runs:

```
[2021-07-11 06:56:49.574 +0000] INFO: Validating credentials
 username: "johndoe"
 scopes: [
 "offline profile email"
 ]
 redirectUrl: "https://example.com/auth/redirect"
```

It is useful because it contains the arguments passed to the `validate` method. A clever log parser can then process this line to separate the log message (_"Validating credentials"_) and the log metadata (_username, scopes, redirectUrl_) to produce clean logs.

## Context of Execution

While the above log statement is alright, it can be better. A key piece of information missing from it is its context of execution, such as the name of the service and the method that produced it, as well as the ID of incoming request that triggered the service.

### Service Name

It's easy to add the name of the service to the logger. Most logging packages support extending a parent logger with some default metadata that is appended to every log line. Therefore we can inject a common base logger, and extend it inside our service's constructor with the service name.

```typescript
@Injectable()
class AuthService {
 private readonly logger: StructuredLogger;

 constructor(
 baseLogger: StructuredLogger,
 private readonly auth0: Auth0Service
 ) {
 this.logger = baseLogger.child({ serviceName: AuthService.name });
 }

 validate = async (creds: Credentials) => {
 this.logger.info({ ...creds }, "Validating credentials");
 // ...
 };
}
```

Now the same log statement includes the service name as well:

```
[2021-07-11 06:56:49.574 +0000] INFO: Validating credentials
 serviceName: "AuthService"
 username: "johndoe"
 scopes: [
 "offline profile email"
 ]
 redirectUrl: "https://example.com/auth/redirect"
```

### Method Name

You can extend the service's logger inside every method to append the `methodName` property to the logger's metadata:

```typescript
validate = async (creds: Credentials) => {
 const methodLogger = this.logger.child({ methodName: "validate" });
 this.logger.info({ ...creds }, "Validating credentials");
 // ...
};
```

Now the same log line contains the `methodName` attribute as well:

```
[2021-07-11 06:56:49.574 +0000] INFO: Validating credentials
 serviceName: "AuthService"
 methodName: "validate"
 username: "johndoe"
 scopes: [
 "offline profile email"
 ]
 redirectUrl: "https://example.com/auth/redirect"
```

### Request ID

The ID of a request is typically contained inside the `x-request-id` header in an incoming request. Therefore, the simplest way of adding it to the logs is to pass the incoming request to the `validate` method, and let it extend its parent logger with a `requestId`.

```typescript
validate = async (creds: Credentials, req: Request) => {
 const requestId = req.headers["x-request-id"];
 const correlationId = req.headers["x-correlation-id"];
 const methodLogger = this.logger.child({
 methodName: "validate",
 reqId: requestId,
 cid: correlationId,
 });
 // ...
};
```

Now the logs include the request ID too:

```
[2021-07-11 06:56:49.574 +0000] INFO: Validating credentials
 serviceName: "AuthService"
 methodName: "validate"
 reqId: "4d426f0a-cf13-47de-a824-f98d98ff7e83"
 cid: "fa38e3d4-6fc0-4bd6-b5cd-cb9f43f994f8"
 username: "johndoe"
 scopes: [
 "offline profile email"
 ]
 redirectUrl: "https://example.com/auth/redirect"
```

It works, _but not really_.

1. It pollutes the signature of the `validate` method, which should only be concerned with the credentials argument.
2. It makes `AuthService` harder to test, as now every test must stub or mock the `req` parameter when testing the `validate` method.
3. It's terribly inconvenient. Extending a logger at every step of execution is a fragile process, and someone on your team can easily forget to do so.

## Injecting a Customized Logger

An alternative solution to this problem is to inject a customized logger using Nest.js that is scoped to a request:

```typescript
export const LoggerProvider: Provider<StructuredLogger> = {
 provide: StructuredLogger,
 scope: Scope.REQUEST,
 useFactory: () => new StructuredLogger(),
};
```

You might be able to do some [ExecutionContext](https://docs.nestjs.com/fundamentals/execution-context) magic and inject a request's ID into this logger, but I'm not sure how. Either way, this solution has the following problems:

1. You're forced to inject a logger instance, even though loggers should be created and destroyed freely.
2. This provider is limited to a _Request Scope_, which means it is recreated on every request. It implies that any service or controller that depends on this provider will **also be request scoped**, regardless of any explicitly specified scope, thus causing needless object allocations on every request.

## Enter: `AsyncLocalStorage`

[`AsyncLocalStorage`](https://nodejs.org/api/async_context.html#async_context_class_asynclocalstorage) is a feature introduced in Node v14 as a part of the `async_hooks` package. It allows you to access an implicitly passed object anywhere in an asynchronous call chain. Its canonical use case is to keep a track of a request ID throughout the request's lifetime.

> While the `async_hooks` API is unstable, the `AsyncLocalStorage` class is considered stable in Node.js. It has been backported to Node.js v12 too.

### Middleware

You can create a functional middleware to create a request context for every incoming request with `AsyncLocalStorage`.

- First, define a global store for storing contexts of every incoming request:

```typescript
interface RequestContext {
 [key: string]: string;
}

const globalStore = new AsyncLocalStorage<RequestContext>();
```

- Then create a couple of convenience methods that enable wrapping a request with a context and accessing that context within the request:

```typescript
// Allows easy access to a request's context
const ctx = (): RequestContext => {
 const context = globalStore.getStore();
 if (!context) {
 throw new NoContextError("No context attached to the current req");
 }
 return context;
};

// Allows wrapping a request in a context
const runWithCtx = (
 fx: (ctx: RequestContext) => Promise<unknown>,
 context: RequestContext = {}
) => {
 globalStore.run(context, () => {
 return fx(ctx());
 });
};
```

- Then create a Nest Functional Middleware that wraps every request in a context:

```typescript
const withContext = (_req: Request, _res: Response, next: NextFunction) => {
 runWithCtx(() => next(), {});
};
```

- Then create a middleware that stores a request's `x-request-id` and `x-correlation-id` headers in the request context:

```typescript
const withRequestId = (req: Request, _res: Response, next: NextFunction) => {
 const context = ctx();
 context.correlationID = req.headers["x-correlation-id"];
 context.requestID = req.headers["x-request-id"];
 return next();
};
```

- Finally, apply the `withContext` and `withRequestId` middleware as early as possible in the Nest application's middleware chain. Ensure that `withContext` executes before `withRequestId`:

```typescript
async function main() {
 const app = await NestFactory.create(AppModule);
 app.useLogger(withContext, withRequestId);
 await app.listen(3000);
}
```

With this setup complete, you can now access the request context implicitly inside any service or controller. I recommend creating a logger factory method to automatically initialize a logger with such details:

```typescript
const createLogger = (
 serviceName: string,
 methodName: string
): StructuredLogger => {
 const context = ctx();
 const { requestId, correlationId } = context;
 const baseLogger = new StructuredLogger();
 const customizedLogger = baseLogger.child({
 serviceName,
 methodName,
 requestId,
 correlationId,
 });
 return customizedLogger;
};
```

### Usage

The `createLogger` method greatly simplifies the logging setup in `AuthService`:

```typescript
@Injectable()
class AuthService {
 constructor(private readonly auth0: Auth0Service) {}

 validate = async (creds: Credentials): Promise<string | Error> => {
 const logger = createLogger(AuthService.name, "validate");
 logger.info({ ...creds }, "Validating credentials");

 const result = await checkCredentials(creds);
 if (!result.success) {
 logger.error({ error: result.error }, "Invalid credentials");
 return result.error;
 }

 logger.info("Credentials valid");
 return result.accessToken;
 };
}
```

1. You no longer need a `logger` parameter in the constructor.
2. The `createLogger` method simplifies extending a base logger with metadata.
3. Since the logger is not a class property anymore, you don't need to access it with `this.logger`.

## Performance Caveat

I like this log setup, but as with everything else in programming, it's a compromise. `AsyncLocalStorage` has a non-negotiable performance hit. It's quite small, but measurable. Make sure to benchmark your setup to check if the convenience is worth the performance penalty.

Here are the results from a rudimentary benchmark for an endpoint that returns _"Hello world!"_ to every request, using the [Apache Benchmarking tool](https://httpd.apache.org/docs/2.4/programs/ab.html). I ran the test on an Apple M1 MacBook Air running Node v16.1.0.

![Request Throughput](/images/asynclocalstorage-logs-nestjs/req-per-sec.svg)
![Request Latency](/images/asynclocalstorage-logs-nestjs/mean-time-per-req.svg)

- Without `AsyncLocalStorage` middlware:

```shell
$ ab -n 1000 -c 100 localhost:3000/greet

Server Software:
Server Hostname: localhost
Server Port: 3000

Document Path: /greet
Document Length: 13 bytes

Concurrency Level: 100
Time taken for tests: 0.201 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 212000 bytes
HTML transferred: 13000 bytes
Requests per second: 4965.98 [#/sec] (mean)
Time per request: 20.137 [ms] (mean)
Time per request: 0.201 [ms] (mean, across all concurrent requests)
Transfer rate: 1028.11 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 0 1 1.0 0 3
Processing: 5 19 5.8 18 33
Waiting: 2 11 4.5 11 29
Total: 5 20 6.4 18 35
WARNING: The median and mean for the initial connection time are not within a normal deviation
 These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
 50% 18
 66% 21
 75% 22
 80% 25
 90% 29
 95% 35
 98% 35
 99% 35
 100% 35 (longest request)
```

- With `AsyncLocalStorage` middlware:

```shell
$ ab -n 1000 -c 100 localhost:3000/greet

Server Software:
Server Hostname: localhost
Server Port: 3000

Document Path: /greet
Document Length: 13 bytes

Concurrency Level: 100
Time taken for tests: 0.219 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 382000 bytes
HTML transferred: 13000 bytes
Requests per second: 4565.08 [#/sec] (mean)
Time per request: 21.905 [ms] (mean)
Time per request: 0.219 [ms] (mean, across all concurrent requests)
Transfer rate: 1702.99 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 0 1 1.1 2 4
Processing: 4 19 8.4 17 41
Waiting: 3 11 6.2 10 38
Total: 5 20 8.9 18 43

Percentage of the requests served within a certain time (ms)
 50% 18
 66% 21
 75% 21
 80% 26
 90% 41
 95% 42
 98% 42
 99% 42
 100% 43 (longest request)
```

4965.98 vs 4565.08 requests per second. I think I can take a loss of 400 requests per second for the added convenience, but you should decide what works for you based on your usecase.

Using request context for more detailed logs

# Backend