Tip: Missing instructions for your LoopBack 3 use case? Please report a Migration docs issue on GitHub to let us know.
It’s often desirable to share contextual data between different parts of an application. For example, a REST connector calling a backend web service may want to forward transaction (correlation) id provided in a HTTP header of the incoming request, or perhaps an auditing component wants to access the information about the user making the request to store it in the log.
LoopBack 3 offers three approaches:
-
The recommended solution is to explicitly pass any contextual information via
optionsargument. Most LoopBack APIs accept (and forward) this argument and there are means how to initialize theoptionsvalue based on the incoming request. -
Code working at REST layer can access and store contextual information on the HTTP request object.
-
An experimental component
loopback-contextuses continuation-local-storage to provide static per-request storage that can be accessed from anywhere inside a LoopBack application (an Express middleware, a model method, a connector, etc.).
In LoopBack 4, extensions should use @inject decorators to access contextual
information. For example:
@inject(key)and@inject.getter(key)to receive values from the context@inject.setter(key)to obtain a setter function for writing values to the context
To keep the contextual data per-request (as opposed to per-application), the
TRANSIENT binding scope should be used.
Components can keep using the old options-based approach where it makes more
sense than Dependency Injection, typically when working with existing
options-based code like Repository APIs.