Middleware for Microservices

[JonathanMeyer2600]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Middleware exists for HTTP but not for Microservices.

Expected behavior

I would like to be able to create middleware functions for Microservices to introduce something like a request context for logging.

Example:

export function MicroserviceMiddleware(context: ExecutionContext, next) {
// .. do some stuff with the context
next()
}

This is different to interceptors because it spans over all guards, interceptors and exception filters.
Or ist there already another way to do this?
Thanks in advance

Environment

Nest version: 5.7.3

[kamilmysliwiec]

Middleware concept exists only for HTTP applications so far.

[skliarovartem]

Did someone find solution how to implement logger with context in microservice?

[Ayzrian]

I am on it :)

[jmcdo29]

@skliarovartem just saw this message, you can use an interceptor to do some request logging in interceptors. That's what I've done with Ogma. It's also got optional request scoping so that you can have the correlationId in each log if you want that too.

[skliarovartem]

I made my tracing by using nestjs-pino + nestjs-steroids/async-context. and yes, I use interceptors to set reqId to context. Thank you for the answer anyway!

[Ayzrian]

I was looking into the code, and I would like to discuss the solution I see at the moment, with the core team, to make sure that I won't spend effort needlessly.

I will split the questions into sections.

Interfaces

Let's start from the fact that the current NestMiddleware interface is very specific to HTTP, so there is two options:

• Making it accept context and next function, where context can be either HTTP Context that contains req and res, or Microservices context/RPC context. Also in the future, we may have Websockets context because that is another module where we missing such a concept. This will be a breaking change and potentially will break compatibility with the function middlewares that exist in the Express ecosystem. I think that it should be possible to distinguish Class middleware and function middelware and hence work around this issue to support Express style middlewares, while all Class middleware will be using new style.
• Creating a new interface e.g. NestMicroservicesMiddleware to solve that specific problem. Again considering that we may want to add middleware to Websockets, we would also create NestWebsocketsMiddleware later.

Configuration

Currently, we expose configure method in the module to do configuration. There is a bit of a difference between HTTP routes and RPC patterns. And hence I see two options:

• Add a different configure method, e.g. configureMicroservices and create dedicated ...ConfigProxy.
• Add a way to provide something like PatternInfo and a forPatterns method in MiddlewareConfigProxy. This entails that we should handle edge cases when someone tries to mix HTTP paths and RPC patterns. Also, imho it t kinda breaks the idea of single responsibility here.

And there are the same concerns regarding the extendability of both approaches if we consider adding Websockets middleware in the future.

Application

Current HTTP middleware relies on the underlying Adapter to mount middleware, due to that fact it is pretty easy to just path the path and handler to the adaptor, and handle exclude config in our custom logic for the handler.

Microservices transports don't have such built-in functions as middleware, so the only way to apply them will be to manually perform the mapping when we create the handler, in the same way, we do with Guards, Interceptors, and so on. This will require the creation of something like MiddlewareContextCreator and MiddlewareConsumer. Our custom handler will always come as the last "middleware".

Other Thoughts

I wonder whether the outcome is worth the effort. The only reasonable way to use middleware in Microservices that I see right now is to use things like AsyncLocalStorage, everything else can be built with Nest.js enhancers. I wonder if we should just expose something like GlobalMiddleware for Microservices, which will wrap every call if someone does need Middleware for something.

[kamilmysliwiec]

everything else can be built with Nest.js enhancers. I wonder if we should just expose something like GlobalMiddleware for Microservices, which will wrap every call if someone does need Middleware for something.

Agree. Maybe we could just allow registering a "preRequest" (where request = event/message) hook so that you can register it for all handlers?

[Ayzrian]

Maybe we could just allow registering a "preRequest" (where request = event/message) hook so that you can register it for all handlers?

Yep, I think that makes sense. That is very close to what I thought when was speaking about GlobalMiddleware.

One note that such preRequest ideally should still receive next or handler function, that will be our handler with enhancers applied, so that something like this would be possible

        asyncLocalStorage.run(context, () => {
            next();
        });

What do you think?

Also while we on that, I think it makes sense to implement similar preRequest for WebSockets, because currently, it is impossible to wrap the Nest.js message handler into AsyncLocalStorage context.

[kamilmysliwiec]

One note that such preRequest ideally should still receive next or handler function, that will be our handler with enhancers applied, so that something like this would be possible

Sounds good. next() should be fine

Also while we on that, I think it makes sense to implement similar preRequest for WebSockets,

We could implement this in a subsequent PR