NestJS Request Scoped Multitenancy for Multiple Databases - multi-tenant

Question

Looking to implement a multi-tenant NestJS solution using the new request injection scope feature of NestJS 6.
For any given service I assume I could do something like this:
#Injectable({scope: Scope.REQUEST})
export class ReportService implements OnModuleInit { ... }
then, in the constructor, determine the tenant from the request, connect to the appropriate database, and instantiate repositories for the new connection.
I'm wondering if this is the most straightforward way to go about it?
Instead of updating each service, is it possible to override the connection provider and scope that to the request?

Answer 1

Here's what we ended up doing...
Create a simple, global TenancyModule bound to the request scope:
tenancy.module.ts
import { Global, Module, Scope } from '#nestjs/common';
import { REQUEST } from '#nestjs/core';
import { getConnection } from 'typeorm';
const connectionFactory = {
provide: 'CONNECTION',
scope: Scope.REQUEST,
useFactory: (req) => {
const tenant = someMethodToDetermineTenantFromHost(req.headers.host);
return getConnection(tenant);
},
inject: [REQUEST],
};
#Global()
#Module({
providers: [connectionFactory],
exports: ['CONNECTION'],
})
export class TenancyModule {}
Inject request-specific 'CONNECTION' into module services from which to retrieve repositories:
user.service.ts
...
#Injectable({scope: Scope.REQUEST})
export class UserService {
private readonly userRepository: Repository<User>;
constructor(#Inject('CONNECTION') connection) {
this.userRepository = connection.getRepository(User);
}

Answer 2

I would recommend to use the approach by #nurikabe with a request scoped factory provider and request scoped services. Nestjs itself has a similar factory example in the docs.
But for the sake of completenes, there is also another approach: You could also use a middleware and attach the connection to the request object as described in this answer to a similar question. However, attaching things like a connection to the request via a middleware is circumventing the DI mechanism and alienates the request object by making it behave like a service container that delivers the connection – therefore the factory approach should be preferred.

Answer 3

It is preferable to inject the connection as a provider (coming from a factory) rather than attaching it to the request.
Note that both approaches will inevitably lead to an increase in the number of connections being created. This can cause performance issues, even with connections pooling. For this reason, such an approach (one connection per tenant) is only really efficient when the number of tenants is relatively low.
One way to do it with a multi-schema approach is fully documented in this article.