Pub-sub and work queue server. Wildcards, streams, back-pressure, multi-transport. Just Node and a filesystem required.

Re-exports all exports of centro-js/lib/client and centro-js/lib/server

Centro client functions

Centro server class

Primus transport. This allows messages to be sent over Primus connections.

TCP transport. This allows messages to be sent over TCP connections.

HTTP transport. This allows messages to be published using HTTP POST requests and received using HTTP Server-Sent Events.

Publish messages using POST requests of the form:

/centro/v2/publish?authz_token=XXX&topic=YYY

• XXX is a JSON Web Token allowing access to the server. See here for more information about Centro authorization tokens.
• YYY is the message's topic. Topics should be in AMQP format: . delimits words.
• The request body should contain the message's data. The server doesn't interpret the data, it just treats it as a binary stream.

Subscribe to messages using GET requests of the form:

/centro/v2/subscribe?authz_token=XXX&topic=YYY&topic=ZZZ

• XXX is the authorization token allowing access to the server.
• YYY is the message topic to which to subscribe. Topics should be in AMQP format: . delimits words, * matches exactly one word and # matches zero or more words.
• You can specify more than one topic, e.g. ZZZ above.

Messages you've subscribed to are delivered using server-sent events. Each message begins with a start event, continues with multiple data events and finishes with an end event.

For example, consider a message with topic foo.bar and body wow. You could receive the following events:

type: start
data: {"id":0,"single":false,"existing":false,"expires":1498375188,"size":3,"topic":"foo.bar"}

type: data
data: {"id":0,"data":"wow"}

type: end
data: {"id":0}

For larger messages you may receive multiple data messages. The event data for each event is JSON-encoded and always contains a message id (in this case 0). If you're receiving multiple messages at the same time, their events may be interleaved so you need to use the id to tell which event is for which message. The id identifies the message for this connection only - it isn't globally unique and the same message may have a different ids on different connections.

In the start event, you'll receive whether the messages is being delivered to a single subscriber, whether it's an existing message (i.e. published before we subscribed), when it expires (in seconds since 1970-01-01), the size of its body data and its topic.

In the data event, you'll receive (part of) the message's body (wow in this case). Since this is JSON-encoded, the data will be a UTF-8 encoded string, even for binary data. If you need to get the raw binary data, encode the string as latin-1 and use the bytes in the result (the server decodes the bytes as latin-1 before JSON encoding the result).

Note that server-sent event IDs and the Last-Event-ID header are not supported because when a connection drops, the server forgets all about it.

HTTP/2 transport. This allows messages to be sent over HTTP/2 streams.

Note that this transport won't work with browser clients. You'll need to use the http2-duplex transport with browsers.

HTTP/2 transport for browsers. This allows messages to be sent over HTTP/2 streams to browsers.

If your client isn't a browser, you should be able to use the http2 transport.

This transport uses the http2-duplex module to emulate a full-duplex connection with browsers. Browser-to-server streaming isn't implemented by any browser, nor are there any plans to do so. http2-duplex emulates it by using POST requests.

In-memory transport. This allows messages to be sent over an in-memory stream to a server running in the same process. The in-memory stream has minimal overhead (the messages aren't copied).

An extra transport operation for this transport is added to the server object:

Create a server which publishes and subscribes to messages on behalf of clients.

Extends events.EventEmitter

Centro extension for defining backoff event behaviour.

Centro extension for closing a connection when an error occurs on it.

Centro extensions for filtering messages.

Centro extension for defining full event behaviour.

Centro extension for limiting the number of active subscriptions, publications and connections.

Centro extension for limiting the total amount of data published and the total number of messages published by a connected client.

Centro extension for limiting the number of concurrent connections each transport supports.

Centro extension for limiting the rate of messages streams.

Centro extension for limiting how long message streams can be open.