Make Vendure serverless proof

Is your feature request related to a problem? Please describe. Most (if not all?) serverless environments don’t allow processing outside the requestcontext. Vendure’s event handling has some async processes that occur outside the requestcontext. For examaple the apply-collection-filters

Event handling occurs after a response has been sent, because event.publish() is fire and forget (as it should be).

Describe the solution you’d like It would be nice if we can somehow be sure that no background tasks are running when a response has been returned.

Describe alternatives you’ve considered One option I see is to be able to implement our own remote eventBus strategy. We could do await eventBus.publish() and be sure that the event is published. Event handling can be done similar to how worker Job’s are handled: in their own async request context if that’s what’s implemented in the implemented ‘eventbus strategy’.

A workaround for Google Cloud Run is to enable background processes, which basically disables the serverless function and makes it a normal running container. (Resulting in a ~3x price increase)

Additional context This problem hasn’t occurred yet, but if an eventhandler does resource intensive tasks that take longer than a few seconds, serverless environments would just kill the process.

This problem can occur with Google Cloud Run, Google Cloud Functions, AWS Lambda and probably similar products from other providers.

Is this something that needs to be implemented in Vendure, or is this a “won’t support” feature? There is no shame in not supporting function/lambda like envs, but semi-serverless/autoscaling envs like Google Cloud Run are great platforms to save costs.

[skid]

Here’s a few thoughts:

1. Vendure internals should not depend on RxJS events, so the code needs to be rewritten to make use of one of the two mechanisms instead of RxJS. The event system as it is now is not serverless-safe, and being async, it does not allow me to actually await the events. So, for example, If I want to react to an Order event and modify the order event before it goes out back to the user - I can’t - because by the time the event handler gets executed, the response is already sent.
2. Instead, Vendure internals should depend on a synchronous event system in combination with a task queue for async event processing. Basically, we should assume that async stuff always happens off-process and everything that is not off-process finishes before the response is sent.
3. The RxJS event system should not be changed or removed because of backwards compatibility, we can deprecate it the mid-term.
4. I understand that a database-polling mechanism is a simple solution for a task queue, but It should not be the bottleneck for improving the platform. I also don’t think the polling mechanism is the problem in itself, but the amount of tasks that are generated. I would have my fans spin up when working locally because on every change Vendure added thousands of events to recalculate the categories (I have a lot of categories). There’s 2 ways to solve this that I can think of: 1) reduce the need for a task queue. For example - reindex products immediately upon saving instead of adding a task. and 2) increase the polling interval (I personally don’t see a problem to have the index be updated after 1,3 or even 10 seconds).
5. Another thing to consider is to ship Redis by default …

[hendrik-advantitge]

It occurs to me that the eventbus and job queue essentially accomplish very similar tasks. Would it be an option to merge the two together?