dadi
Background hook execution
Currently all hooks need to complete before a response is returned. This has negative side-effects, in terms of performance, when a collection write request triggers, via beforeUpdate or afterUpdate hook, several additional write requests into other collections. These additional requests could run asynchronously in the background, as they are not needed for the response to the initial one. At present there is no way to control hooks execution and run them "in the background" when needed. Although this could be done inside the hook itself, the best option would be to have a specific parameter in the hook definition that defines when the hook has to run synchronously or asynchronously. The current behaviour (synchronous) should be the default one.
@eduardoboucas I have a working background processor for this, but would like your assistance to move it forward.
I don't think before hooks should ever run in the background, because their main purpose is to be able to intercept and modify the request, possibly even aborting it completely. If you don't need to do that, a after hook seems to me like the best option.
When you say "in the background", what do you have in mind? Just getting it out of the event loop (with a setTimeout, for example) or actually spawning another process? Depending on how complex we envision this to be, I'd suggest we reconsider the possibility of allowing each hook to define this behaviour.
If we do want to go ahead and make API handle this, I don't think I'd use a flag. Maybe another type of hook (beforeCreate, afterCreate and somethingCreate) would be cleaner and easier to document.
Agree on the before hooks. This is definitely an after kinda thing.
I have it spawning another process, correct. I think it's ok to handle it in the existing after hooks - otherwise when do we call it? We might be making the model too complex by introducing another hook trigger?
What if we make that the default behaviour for afterCreate, afterUpdate and afterDelete, so always run them as a separate process? (Not afterGet, as we use that one to modify the response)
I still think making after hooks asynchronous is the simplest way to handle this. To build this, we just need to decide on what running a hook in the background actually means.
Do we need a separate process? I believe @jimlambie did some investigation on this and was not happy with the results of that approach – could you elaborate?
If not, is it enough to get the execution out of the event loop so that the execution of the after hooks can happen after the response has been delivered?