@fastify/request-context

Request-scoped storage support, based on AsyncLocalStorage.

Inspired by work done in fastify-http-context.

This plugin introduces thread-local request-scoped HTTP context, where any variables set within the scope of a single HTTP call will not be overwritten by simultaneous calls to the API nor will variables remain available once a request is completed.

Frequent use-cases are persisting request-aware logger instances and user authorization information.

Install

npm i @fastify/request-context

Compatibility

Plugin version	Fastify version
>=6.x	^5.x
>=4.x <6.x	^4.x
>=2.x <4.x	^3.x
^1.x	^2.x
^1.x	^1.x

Please note that if a Fastify version is out of support, then so are the corresponding versions of this plugin in the table above. See Fastify's LTS policy for more details.

Getting started

Set up the plugin:

1const { fastifyRequestContext } = require('@fastify/request-context')
2const fastify = require('fastify');
3
4fastify.register(fastifyRequestContext);

Or customize hook and default store values:

1const { fastifyRequestContext } = require('@fastify/request-context')
2const fastify = require('fastify');
3
4fastify.register(fastifyRequestContext, {
5  hook: 'preValidation',
6  defaultStoreValues: {
7    user: { id: 'system' }
8  }
9});

Default store values can be set through a function as well:

1const { fastifyRequestContext } = require('@fastify/request-context')
2const fastify = require('fastify');
3
4fastify.register(fastifyRequestContext, {
5  defaultStoreValues: request => ({
6    log: request.log.child({ foo: 123 })
7  })
8});

This plugin accepts options hook and defaultStoreValues, createAsyncResource.

• hook allows you to specify to which lifecycle hook should request context initialization be bound. Note that you need to initialize it on the earliest lifecycle stage that you intend to use it in, or earlier. Default value is onRequest.
• defaultStoreValues / defaultStoreValues(req: FastifyRequest) sets initial values for the store (that can be later overwritten during request execution if needed). Can be set to either an object or a function that returns an object. The function will be sent the request object for the new context. This is an optional parameter.
• createAsyncResource can specify a factory function that creates an extended AsyncResource object.

From there you can set a context in another hook, route, or method that is within scope.

Request context (with methods get and set) is exposed by library itself, but is also available as decorator on fastify.requestContext app instance as well as on req request instance.

For instance:

1const { fastifyRequestContext, requestContext } = require('@fastify/request-context')
2const fastify = require('fastify');
3
4const app = fastify({ logger: true })
5app.register(fastifyRequestContext, {
6  defaultStoreValues: {
7    user: { id: 'system' }
8  },
9  createAsyncResource: (req, context) => new MyCustomAsyncResource('custom-resource-type', req.id, context.user.id)
10});
11
12app.addHook('onRequest', (req, reply, done) => {
13  // Overwrite the defaults.
14  // This is completely equivalent to using app.requestContext or just requestContext
15  req.requestContext.set('user', { id: 'helloUser' });
16  done();
17});
18
19// this should now get `helloUser` instead of the default `system`
20app.get('/', (req, reply) => {
21  // requestContext singleton exposed by the library retains same request-scoped values that were set using `req.requestContext`
22  const user = requestContext.get('user');
23
24  // read the whole store
25  const store = req.requestContext.getStore();
26  reply.code(200).send( { store });
27});
28
29app.get('/decorator', function (req, reply) {
30  // requestContext singleton exposed as decorator in the fastify instance and can be retrieved:
31  const user = this.requestContext.get('user'); // using `this` thanks to the handler function binding
32  const theSameUser = app.requestContext.get('user'); // directly using the `app` instance
33  reply.code(200).send( { user });
34});
35
36app.listen({ port: 3000 }, (err, address) => {
37  if (err) throw err
38  app.log.info(`server listening on ${address}`)
39});
40
41return app.ready()

TypeScript

In TypeScript you are expected to augment the module to type your context:

1import {requestContext} from '@fastify/request-context'
2
3declare module '@fastify/request-context' {
4  interface RequestContextData {
5    foo: string
6  }
7}
8
9// Type is "string" (if "strictNullChecks: true" in your tsconfig it will be "string | undefined")
10const foo = requestContext.get('foo')
11// Causes a type violation as 'bar' is not a key on RequestContextData
12const bar = requestContext.get('bar')

If you have "strictNullChecks": true (or have "strict": true, which sets "strictNullChecks": true) in your TypeScript configuration, you will notice that the type of the returned value can still be undefined even though the RequestContextData interface has a specific type. For a discussion about how to work around this and the pros/cons of doing so, please read this issue (#93).

Usage outside of a request

If functions depend on requestContext but are not called in a request, i.e. in tests or workers, they can be wrapped in the asyncLocalStorage instance of requestContext:

import { asyncLocalStorage } from '@fastify/request-context';

it('should set request context', () => {
  asyncLocalStorage.run({}, async () => {
    requestContext.set('userId', 'some-fake-user-id');
    someCodeThatUsesRequestContext(); // requestContext.get('userId') will work
  })
})

License

Licensed under MIT.