Another server-side use case is a background queue, such as AWS SQS. This module could allow the Ballast API to run on top of an SQS queue, implemented as an Input strategy.
Inputs sent to the VM would be automatically serialized and placed into the queue. Any other distributed server could then read from the queue, deserialize the input, and then process it.
A first POC should disable the use of State through the use of a custom InputStrategy Guardian. This would effectively make a Ballast distributed queue a purely Stateless queue. Future work could add some way to store and rehydrate state for each Input pulled from the queue, which would allow it to process longer distributed "user journeys".
Further extensions could support specific types of common Java server-side queues, like sending transactional emails, SMS messages, or push notifications.
Open questions are mostly the same as with the Scheduler.
Another server-side use case is a background queue, such as AWS SQS. This module could allow the Ballast API to run on top of an SQS queue, implemented as an Input strategy.
Inputs sent to the VM would be automatically serialized and placed into the queue. Any other distributed server could then read from the queue, deserialize the input, and then process it.
A first POC should disable the use of State through the use of a custom InputStrategy Guardian. This would effectively make a Ballast distributed queue a purely Stateless queue. Future work could add some way to store and rehydrate state for each Input pulled from the queue, which would allow it to process longer distributed "user journeys".
Further extensions could support specific types of common Java server-side queues, like sending transactional emails, SMS messages, or push notifications.
Open questions are mostly the same as with the Scheduler.