Nats Plugin

[dfarr]

Resonate should support NATSio as a plugin for the sender subsystem.

Sender subsystem

The sender subsystem is responsible for sending messages on supported transports (http, sqs, etc) via plugins. Currently Resonate supports:

• http
• polling

The nats plugin is responsible for sending a message on a nats queue. A message is a tuple of (data, body). The body is a byte array containing the raw information to put on the SQS queue, the data is all the meta information needed to route a message to a nats queue and can be defined per plugin. With these two pieces of information the plugin should be able to enqueue a message, once enqueued the plugin is responsible for calling the done function on the message.

Router subsystem

In addition to the sender plugin we will need to extend the router plugin to parse nats urls. By default, Resonate matches promises by looking for the presence of a resonate:invoke tag, this tag can contain either:

• a logical receiver (a string name that will be resolved to a physical receiver later)
• a json physical receiver
• a url physical receiver

For nats, a fully defined physical receiver may look like:

{ "type": "nats", "data": { "url": "nats://localhost:4222, "queue": "my-queue", ... } }

A url physical receiver is a convenience that encodes some of the above information in a url, the scheme must match the type of the plugin - in this case nats. For nats this could look something like:

nats://localhost:4222/my-queue

See this function to see how we parse http and poll urls.

[dfarr]

We should use the queue group feature of nats to implement message routing to a single node in the queue group.