Prehandler support #75
Conversation
…lkit into feat/prehandlers # Conflicts: # packages/core/index.ts
|
@dariacm @CarlosGamero This PR was two months in the making, I don't want to delay it any further, so I'll tackle the documentation in a separate PR; it's been high time we've started writing dialect-specific documentation too, so I'll incorporate it into the larger docs rework. |
| const prehandlerOutput = await this.processPrehandlers(message, messageType) | ||
| const barrierResult = await this.preHandlerBarrier(message, messageType, prehandlerOutput) |
There was a problem hiding this comment.
No part of this PR.
If the barrier doesn't allow the message to be consumed we will execute preHandlers again, so maybe as a future improvement do you think that could make sense to somehow store preHandlers results and avoid executing them again?
To be clear, I think it is fine and I am not suggesting doing it now, just thinking about the possibility
There was a problem hiding this comment.
It would be great, but I doubt a fully universal solution is possible here. Imagine a prehandler with permission checks - if permissions changed since the last time we checked, prehandler results may be different.
Caching downstream on a case-by-case basis (e. g. how we cache user data in user plugin now) looks like a more feasible approach.
There was a problem hiding this comment.
I see, a fully universal solution doesn't seem to be the right approach you are right, so yeah, we would need to go with a case-by-case one 💯 but that is something for future improvement :D
| // MonoSchema support is going away in the next semver major, so we don't care about coverage strongly | ||
| /* c8 ignore start */ | ||
| // eslint-disable-next-line max-params |
There was a problem hiding this comment.
Nice! removing mono consumers will help to speed up development on the library 🙌, thanks Igor 🙇
No description provided.