Easiest way to integrate MikroORM to Nest is via
Simply install it next to Nest, MikroORM and underlying driver:
Once the installation process is completed, we can import the
MikroOrmModule into the root
forRoot() method accepts the same configuration object as
init() from the MikroORM package. Check this page for the complete configuration documentation.
Alternatively we can configure the CLI by creating a configuration file
mikro-orm.config.ts and then call the
forRoot() without any arguments. This won't work when you use a build tools that use tree shaking.
EntityManager will be available to inject across entire project (without importing any module elsewhere).
Notice that the
EntityManageris imported from the
@mikro-orm/driverpackage, where driver is
postgresor what driver you are using.
In case you have
@mikro-orm/knexinstalled as a dependency, you can also import the
MikroORM supports the repository design pattern. For every entity we can create a repository. Read the complete documentation on repositories here. To define which repositories shall be registered in the current scope you can use the
forFeature() method. For example, in this way:
You should not register your base entities via
forFeature(), as there are no repositories for those. On the other hand, base entities need to be part of the list in
forRoot()(or in the ORM config in general).
and import it into the root
In this way we can inject the
PhotoRepository to the
PhotoService using the
When using custom repositories, we can get around the need for
decorator by naming our repositories the same way as
getRepositoryToken() method do:
In other words, as long as we name the repository same was as the entity is called,
Repository suffix, the repository will be registered automatically in
the Nest.js DI container.
As the custom repository name is the same as what
return, we do not need the
@InjectRepository() decorator anymore:
autoLoadEntitiesoption was added in v4.1.0
Manually adding entities to the entities array of the connection options can be tedious. In addition, referencing entities from the root module breaks application domain boundaries and causes leaking implementation details to other parts of the application. To solve this issue, static glob paths can be used.
Note, however, that glob paths are not supported by webpack, so if you are building
your application within a monorepo, you won't be able to use them. To address this
issue, an alternative solution is provided. To automatically load entities, set the
autoLoadEntities property of the configuration object (passed into the
true, as shown below:
With that option specified, every entity registered through the
method will be automatically added to the entities array of the configuration
Note that entities that aren't registered through the
forFeature()method, but are only referenced from the entity (via a relationship), won't be included by way of the
autoLoadEntitiesalso has no effect on the MikroORM CLI - for that we still need CLI config with the full list of entities. On the other hand, we can use globs there, as the CLI won't go through webpack.
@UseRequestContext()decorator was added in v4.1.0
As mentioned in the docs, we need a clean state for each request. That is handled automatically thanks to the
RequestContext helper registered via middleware.
But middlewares are executed only for regular HTTP request handles, what if we need a request scoped method outside of that? One example of that is queue handlers or scheduled tasks.
We can use the
@UseRequestContext() decorator. It requires you to first inject the
MikroORM instance to current context, it will be then used to create the context
for you. Under the hood, the decorator will register new request context for your
method and execute it inside the context.
The GraphQL module in NestJS uses
apollo-server-express which enables
bodyparser by default. (source) As mentioned in "RequestContext helper for DI containers" this causes issues as the Middleware the NestJS MikroORM module installs needs to be loaded after
This can be done by adding bodyparser to your main.ts file
And at the same time disabling the bodyparser in the GraphQL Module
AsyncLocalStorage for request context#
By default, the
domain api is used in the
RequestContext helper. Since
you can use the new
AsyncLocalStorage too, if you are on up to date node version:
@mikro-orm/nestjs package exposes
getRepositoryToken() function that returns prepared token based on a given entity to allow mocking the repository.
A real world example of NestJS with MikroORM can be found here