The RequestContext holds information relevant to the current request, which may be required at various points of the stack.
It is a good practice to inject the RequestContext (using the Ctx decorator) into all resolvers & REST handler, and then pass it through to the service layer.
This allows the service layer to access information about the current user, the active language, the active Channel, and so on. In addition, the TransactionalConnection relies on the presence of the RequestContext object in order to correctly handle per-request database transactions.
Example
Example
() => RequestContextCreates an "empty" RequestContext object. This is only intended to be used
when a service method must be called outside the normal request-response
cycle, e.g. when programmatically populating data. Usually a better alternative
is to use the RequestContextService create() method, which allows more control
over the resulting RequestContext object.
The apiType of admin is a placeholder, not a statement about a caller. A session created
from such a context records the Shop API, see SessionService.createNewAuthenticatedSession().
(ctxObject: SerializedRequestContext) => RequestContextCreates a new RequestContext object from a serialized object created by the
serialize() method.
(permissions: Permission[], channelId: ID = this.channelId) => booleanReturns true if there is an active Session & User associated with this request,
and that User has at least one of the specified permissions on the given Channel.
The Channel defaults to the active Channel of this request.
This method uses OR logic - it checks if the user has ANY of the given permissions,
not ALL of them. For AND logic, use userHasAllPermissions.
Example
Returns true if there is an active Session & User associated with this request,
and that User has all of the specified permissions on the given Channel.
The Channel defaults to the active Channel of this request.
This method uses AND logic - it checks if the user has EVERY one of the given permissions.
For OR logic (any permission), use userHasPermissions.
Example
() => SerializedRequestContextSerializes the RequestContext object into a JSON-compatible simple object. This is useful when you need to send a RequestContext object to another process, e.g. to pass it to the Job Queue via the JobQueueService.
The raw Express request (and with it every HTTP header) and the session token are
not included, because serialized contexts are persisted and are readable over the
Admin API. A context rebuilt with deserialize() therefore has req and
session.token set to undefined.
() => SerializedRequestContextUsed by JSON.stringify() and by Job, which prefers toJSON() when it makes
job data serializable. A RequestContext instance passed straight into job data therefore
takes the same path as serialize().
(channel?: Channel) => RequestContextCreates a shallow copy of the RequestContext instance. This means that mutations to the copy itself will not affect the original, but deep mutations (e.g. copy.channel.code = 'new') will also affect the original.
Passing a channel re-scopes the copy to it, switching language and currency
to the channel's defaults so downstream logic runs in the target channel.
Request | undefinedThe raw Express request object.
This is undefined on a context which was rebuilt from a serialized object, e.g. in a
job queue worker, because the request is deliberately not serialized. It is also undefined on
a context built outside the request-response cycle, which is how
SessionService.createNewAuthenticatedSession() tells a stated apiType from a placeholder
one. Do not populate it on a synthetic context.
ApiTypeSignals which API this request was received by, e.g. admin or shop.
ChannelThe active Channel of this request.
IDLanguageCodeThe languages the client asked to read this response in, most preferred first, taken from the
Accept-Language header. Empty when the client sent no header.
RequestContext.languageCode selects which translation of the data to return. These
codes say which language the server should write its own text in, such as the descriptions
and labels attached to a ConfigurableOperationDef. The two differ for an
administrator reading the Admin UI in Japanese while editing the German translation of a
product.
A code here is not guaranteed to be a member of the LanguageCode enum, for the same
reason languageCode is not: custom codes are permitted. A code with no translation behind
it matches nothing and is skipped.
CurrencyCodeCachedSession | DeserializedCachedSession | undefinedThe cached session of this request.
On a context which was rebuilt from a serialized object, e.g. in a job queue worker, this is
a DeserializedCachedSession: session.token is undefined, because the token is
deliberately not serialized. The class cannot tell the two apart statically, so the type of
session.token is string | undefined everywhere. Narrow it before using it as a credential.
ID | undefinedbooleanTrue if the current session is authorized to access the current resolver method.
booleanTrue if the current anonymous session is only authorized to operate on entities that are owned by the current session.
(key: string, variables?: { [k: string]: any }) => stringTranslate the given i18n key
(mode: ReplicationMode) => voidSets the replication mode for the current RequestContext. This mode determines whether the operations within this context should interact with the master database or a replica. Use this method to explicitly define the replication mode for the context.
ReplicationMode | undefinedGets the current replication mode of the RequestContext. If no replication mode has been set,
it returns undefined. This property indicates whether the context is configured to interact with
the master database or a replica.
Architecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.
Talk to the teamThe RequestContext also provides mechanisms for managing the database replication mode via the
setReplicationMode method and the replicationMode getter. This allows for finer control
over whether database queries within the context should be executed against the master or a replica
database, which can be particularly useful in distributed database environments.