This package provides an easy way to communicate with a message queue using our messaging protocol.
Clone the repository and run npm install
.
The package.json includes scripts to run all tests. Just run npm test
!
The messaging protocol is built directly on top of TCP and follows the simple syntax of <KEYWORD> <DATA>
. Available keywords are as follows:
Adds a new task to the queue. Messages need to follow the syntax
SCHED <data>[@<service>]
The @<service>
is optional and defines which listening service should execute the task. If not supplied, the task will be added to a default
queue.
SCHED { email: "test@test.de", message: "test message" }@EMAILSERVICE
Schedules a task for services listening to the EMAILSERVICE
queue. The task is encoded as a JSON object and contains an email address and a message.
The data part does not have to be JSON as we will see in the next example. In the context of the studybear backend however, we will always encode
tasks as JSON objects.
SCHED test
This is more of a minimum working example. Schedules the task “test” for services listing to the default
queue.
Asks for a task from the queue. The full syntax is
ASK [service]
Again, the service
parameter is optional and the default
queue is accessed if omitted. Prompts the messaging queue to respond with a WANT?
message.
ASK EMAILSERVICE
Asks for a new task from the EMAILSERVICE
queue.
ASK
Asks for a new task from the default
queue.
Sent by the messaging queue to supply a task to a service. The full syntax is
WANT? <data>
The data represents the task, and is equivalent to the data in the SCHED
message.
WANT? { email: "test@test.de" message: "test message" }
Returns the same task we scheduled in the SCHED
section.
Sent by the messaging queue to indicate that there are no available tasks in the requested queue.
Confirms the acceptance of a WANT?
message. The messaging queue assumes that the task will be done successfully and will remove it from the relevant
queue. Should the receiving service fail in fulfilling the task, it has to be re SCHED
uled.
Declines the task. The messaging queue will skip it and move it to the back of the queue. Can be used to postpone tasks. ATTENTION the messaging
queue will not respond with another WANT?
message, the client needs to ASK
again.
Removes the task from the messaging queue. This may be useful if the task data is corrupted or not readable for some other reason. To avoid blocking the
queue with tasks that will be DCL
ined anyway, services can use DEL
to remove them.
Ends the communication and closes the socket.