Someone asked in the Resonate Discord:
What is the benefit of using Resonate over a job queue?
Persisting a job to a queue implies that there is no single place where the business logic of the application is defined. Essentially, a distributed application relies on various services or components to each play a part and then hand off the next step to another. In practice, this makes it very difficult for a single developer to learn, reason about, and contribute to the application’s business flow.
At a high level, Resonate offers a sequential-looking programming model built on top of a concurrent execution model (such as a job queue).
One could argue that a Resonate Function consisting of a single span or step, and a job on a traditional job que…
Someone asked in the Resonate Discord:
What is the benefit of using Resonate over a job queue?
Persisting a job to a queue implies that there is no single place where the business logic of the application is defined. Essentially, a distributed application relies on various services or components to each play a part and then hand off the next step to another. In practice, this makes it very difficult for a single developer to learn, reason about, and contribute to the application’s business flow.
At a high level, Resonate offers a sequential-looking programming model built on top of a concurrent execution model (such as a job queue).
One could argue that a Resonate Function consisting of a single span or step, and a job on a traditional job queue, are functionally equivalent. The difference lies in the developer experience and the ease of reasoning about the application’s business logic.
It is also important to note that a Resonate Application Node can act as both a consumer and a producer between job queues — effectively serving as a processor. It naturally avoids head-of-line blocking issues and provides a durable bridge between queues.
Furthermore, Resonate can use job queues to pass messages between Resonate Servers and Application Nodes.