Server-Hooks in Adonis V6 | Running actions after response globally/for all endpoints

[maxifuchs]

Hey Team,

I have the usecase/requirement that I need to log certain infos about every request that reached the server, both successful and failed ones.
These infos must include the status-code of the response, which makes it more challenging, since therefore it needs to be logged after the response was sent to the client.
My desired output basically looks like this:

"POST-Request: /someEndpoint; StatusCode: 200; IP: '0.0.0.0'; Username: 'User5'; Data: '{\"property1\":[\"test1\",\"test2\"],\"property2\":\"test3\"}'"

In Adonis V5, i used the

import Server from '@ioc:Adonis/Core/Server'

Server.hooks.after(async (ctx) => {
    ...
})

function to get access to the data after the response was sent to the client, which worked great. Apparently the Server-Hooks don't exist anymore though in Adonis V6.

I did find this section in the Docs about running actions after the response finishes (https://docs.adonisjs.com/guides/basics/response#running-actions-after-response-finishes), which could be partly suitable for my usecase.

However the docs make it seem that i would need to include that snippet into every single endpoint, which would certainly lead to errors down the line when someone forgets it etc and also leads to code duplication...
And it doesnt seem to work on errors, which were thrown by the middleware and didnt even reach the endpoint...

Are the server hooks really gone in V6? And if thats the case, is it possible to use the "response.onFinish()" method globally somehow for all Endpoints without having to write it into each single one?
Or is there some other more elegant solution?

Thanks a lot

[thetutlage]

You can do it via middleware. https://docs.adonisjs.com/guides/basics/middleware#mutating-response-from-a-middleware

[maxifuchs]

Ahhh ok, thanks:)
I did see it in the docs, but to me it sounded like it would only apply to mutating the response and was still done before the response was send...
But it does make sense, since the code then runs when the normal logic is all done and finished, therefore we don't expect an error to occur afterwards and the status code is therefore accurate

If someone else stumbles over it in the future: the status code is accurate in the response.response.statusCode property, not the response.statusCode one