Idea to remove the MikroOrmMiddleware in favor of a Interceptor variant

[tolgap]

I'm starting to implement a microservice architecture. But I ran into the issue of RequestContext not being setup for RPCs. That's because NestJS middlewares only work for the HTTP adapter.

I would like to suggest the removal of this middleware, and switch it out with an Interceptor variant. The interceptor that I wrote to make it work for my @nestjs/microservices app is as following:

import { EntityManager, RequestContext } from '@mikro-orm/core';
import {
  CallHandler,
  ExecutionContext,
  Injectable,
  NestInterceptor,
} from '@nestjs/common';
import { lastValueFrom, Observable, of } from 'rxjs';

@Injectable()
export class MikroOrmInterceptor implements NestInterceptor {
  constructor(private readonly em: EntityManager) {}

  intercept(
    context: ExecutionContext,
    next: CallHandler
  ): Observable<unknown> | Promise<Observable<unknown>> {
    // Would be nice to also be able to use this for other types of requests (`http`, `graphql`, etc) but that's being handled by the middleware at the moment.
    if (context.getType() !== 'rpc') {
      return next.handle();
    }

    return this.ensureRequestContext(next);
  }

  private ensureRequestContext<T = unknown>(next: CallHandler<T>) {
    return RequestContext.createAsync<Observable<T>>(this.em, async () =>
      of(await lastValueFrom(next.handle()))
    );
  }
}

@B4nan what do you think?

[B4nan]

What about the performance? Would be good to measure this on the https://github.com/mikro-orm/nestjs-realworld-example-app.

Even if it would be slower, we can have that as opt-in, PR welcome for that.

[tolgap]

As I was implementing this in the realworld example app, I realized this isn't for everyone.

Since interceptors work as Observable and it could be possible to emit values over a span of time, its practically impossible to achieve this. You could run into a scenario where your RequestContext could live a very long time while the Observable keeps spitting out more values over a period of long time. But seeing as RequestContext is a Promise that cannot "omit" something like this, you're basically forced to let an incoming request wait for the entire Observable to complete before returning any data from it.

If you're planning on using MikroORM in a microservices architecture, beware of this. I would suggest injecting the EntityManager manually and calling em.fork() on it. And at the end of your Observable just calling em.clear().

[tolgap]

@B4nan if you're wondering, I setup the /api/articles route of the realworld app with 25 articles.

I then use Apache Benchmark to run 50 consecutive requests for a total of 5000 requests with the following command:

ab -k -c 50 -n 5000 http://localhost:3000/api/articles

This is the output for the middleware solution (default untouched codebase, just master branch):

Default middleware

Finished 5000 requests


Server Software:        
Server Hostname:        localhost
Server Port:            3000

Document Path:          /api/articles
Document Length:        7304 bytes

Concurrency Level:      50
Time taken for tests:   6.660 seconds
Complete requests:      5000
Failed requests:        0
Keep-Alive requests:    5000
Total transferred:      37875000 bytes
HTML transferred:       36520000 bytes
Requests per second:    750.75 [#/sec] (mean)
Time per request:       66.600 [ms] (mean)
Time per request:       1.332 [ms] (mean, across all concurrent requests)
Transfer rate:          5553.66 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:    45   66   9.1     63     141
Waiting:       45   66   9.1     63     141
Total:         45   66   9.2     63     142

Percentage of the requests served within a certain time (ms)
  50%     63
  66%     66
  75%     69
  80%     71
  90%     77
  95%     84
  98%     92
  99%     97
 100%    142 (longest request)

This is the output for the logic with registerRequestContext: false and setting up an APP_INTERCEPTOR that provides an interceptor that utilizes RequestContext.create before each request:

RequestContext Interceptor

Finished 5000 requests


Server Software:        
Server Hostname:        localhost
Server Port:            3000

Document Path:          /api/articles
Document Length:        8187 bytes

Concurrency Level:      50
Time taken for tests:   6.798 seconds
Complete requests:      5000
Failed requests:        0
Keep-Alive requests:    5000
Total transferred:      42290000 bytes
HTML transferred:       40935000 bytes
Requests per second:    735.54 [#/sec] (mean)
Time per request:       67.978 [ms] (mean)
Time per request:       1.360 [ms] (mean, across all concurrent requests)
Transfer rate:          6075.37 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       2
Processing:    36   67   9.2     65     147
Waiting:       34   67   9.2     65     147
Total:         36   67   9.3     65     149

Percentage of the requests served within a certain time (ms)
  50%     65
  66%     68
  75%     70
  80%     72
  90%     77
  95%     84
  98%     96
  99%    103
 100%    149 (longest request)

But I have no way of really knowing how well it would run in a microservices architecture where we would use eventsourcing and using long-living Observable that omits values over a long time.

[tolgap]

Also as a side-note: This solution would only work in NestJS v10: nestjs/nest#11142