Unable to execute server-level middleware after response is sent using InversifyExpressServer

[madmatah]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

I would like to run some server-level middlewares (that are not error handlers) after the HTTP response has been sent.

For example, I want to log all status codes returned by my server:

const statusCodeLoggerMiddleware = (req, res, next) => {
  console.log(`STATUS: ${res.statusCode}`);
  next();
};

@controller('/test')
export class TestController extends BaseHttpController {
  @httpGet('/success') public getSuccess() {
    return 'OK';
  }

  @httpGet('/teapot') public getTeapot() {
    return this.statusCode(418);
  }
}

const container = new Container();
const server = new InversifyExpressServer(container);

server.setErrorConfig((app) => {
  app.use(statusCodeLoggerMiddleware);
});

const app = server.build();

I used setErrorConfig() method to register my middleware after the controller routes.
But it is never executed.

Did I miss something to get the expected result?

Steps to reproduce

No response

Expected behavior

I expect middlewares registered after the controller routes to be executed.
In the current state, only error handlers are executed.

Possible solution

I think the handlerFactory() method in InversifyExpressServer should call next() after the response is sent:

private handlerFactory(
        controllerName: string,
        key: string,
        parameterMetadata: ParameterMetadata[]
    ): RequestHandler {
        return async (req: Request, res: Response, next: NextFunction): Promise<void> => {
            try {
                 [...]
                 next();
            } catch (err) {
                next(err);
            }
        };
    }

I can make a PR if this solution is OK for you.

Package version

6.2.1

Node.js version

20.11.1

In which operating systems have you tested?

• macOS
• Windows
• Linux

Stack trace

No response

Other

inversify-express-utils version 6.4.10

[notaphplover]

Hey @madmatah, setErrorConfig sets the handler to be executed as a fallback in case the request handler fails, consider using @withMiddleware instead. I tested it locally and worked like a charm:

const statusCodeLoggerMiddleware = (req, res, next) => {
  console.log(`STATUS: ${res.statusCode}`);
  next();
};

@controller('/test')
@withMiddleware(statusCodeLoggerMiddleware)
export class TestController extends BaseHttpController {
  @httpGet('/success') public getSuccess() {
    return 'OK';
  }

  @httpGet('/teapot') public getTeapot() {
    return this.statusCode(418);
  }
}

const container = new Container();
const server = new InversifyExpressServer(container);

const app = server.build();

I'll close the issue, but we can keep discussing it if you have any doubt.

[madmatah]

Hello @notaphplover and thank you for your reply!

The example that you gave using @withMiddleware does not work as expected :
When I make a HTTP request GET /test/teapot I get a response with status code 418. But the middleware logs STATUS: 200 instead of STATUS: 418.

And that's because the middleware is registered for execution before my controller code.

The main point of this issue is that I want to be able to run middleware after the response has been sent. I've taken a simple example here to illustrate my problem, but a more realistic example would be to create middleware that collects statistics on the response time of all my routes.

I can do it easily with express, but I'm stuck to do it with InversifyExpressServer.

And the second point is that I'm looking for a way to declare this kind of middleware on a server-level, to execute it everytime. I don't want to decorate all my controllers for this use case. The setConfig() method allows to declare "server level middlewares" that are executed before the controller, and I'm looking for a way to register middlewares after the response has been sent. That's why i mentionned setErrorConfig(), but i'm aware that it's not it's original purpose.

[notaphplover]

Hey @madmatah , I see. being totally honest I thought when a middleware ends the request response cycle, the next middleware should not be invoked, but after having a look at the docs it's not forbidden.

I'm reopening the issue now

[santosh-sambhavani]

Hi @madmatah this worked for me.

const statusCodeLoggerMiddleware = (req, res, next) => {
  console.log(`STATUS: ${res.statusCode}`);
  next();
};

@controller("/test")
export class TestController extends BaseHttpController {
  @httpGet("/success") public getSuccess() {
    return "OK";
  }

  @httpGet("/teapot") public getTeapot() {
    return this.statusCode(418);
  }
}

const container = new Container();
const server = new InversifyExpressServer(container);

server.setConfig((app) => {
  app.use(statusCodeLoggerMiddleware);
});

const app = server.build();

app.listen("3000", () => {
  console.log("Server is running on 3000");
});

server.serErrorConfig works only when we are throwing error. for normal response apis we can use server.setConfig

[madmatah]

@notaphplover Thanks! Indeed, Express is quite permissive and both ways of doing things are valid.

In order not to break anything, how about making this behaviour configurable by adding an option to the InversifyExpressServer constructor? (e.g. callNextMiddlewareAfterResponse ?: boolean with default value false)

[madmatah]

@santosh-sambhavani Hello and thanks for your response. This example does not work as expected: the middleware is executed before the controller.

If I start the server and make a GET /test/teapot request, I get:

Server is running on 3000
STATUS: 200

The expected result is STATUS: 418.