Synchronize service events between application instances using Redis or MongoDB publish/subscribe
When running multiple instances of your Feathers application (e.g. on several Heroku Dynos), service events (created, updated, patched, removed) do not get propagated to other instances. feathers-sync uses MongoDB publish/subscribe via mubsub or Redis via redis to propagate all events to all application instances.
This allows to scale real-time websocket connections to any number of clients.
The application initialized in the following example will use the local feathers-sync database and sync collection and share service events with every other instance connected to the same database:
var feathers = require('feathers');
var sync = require('feathers-sync');
var app = feathers();
app.configure(feathers.rest())
.configure(feathers.socketio())
.configure(sync({
db: 'mongodb://localhost:27017/sync',
collection: 'events'
}))
.use('/todos', todoService);
app.listen(3000);- db - The MongoDB connection string (e.g.
mongodb://localhost:27017/events) or database object - collection - The name of the capped event collection (default is
events) - connect - A callback for when the MongoDB connection has been established
- mubsub - Settings to be passed to mubsub (e.g.
{authSource:'admin'})
Additionally you can pass the original sync options:
- size - Max size of the collection in bytes, default is 5mb
- max - Max amount of documents in the collection
- retryInterval - Time in ms to wait if no docs are found, default is 200ms
- recreate - Recreate the tailable cursor when an error occurs (default is
true)
- db - The Redis connection string (e.g.
redis://localhost:6379) or database object - connect - A callback for when the Redis connection has been established
- uri - The AMQP connection string (e.g.
amqp://guest:guest@localhost:5672) - prefix - A prefix that will be applied to all queues, exchanges and messages created by sync
- amqpConnectionOptions - AMQP connection options
When listening to service events with this, all events are going to get propagated to all clients. This means, that your event listeners should not perform any actions that change the global state (e.g. write something into the database) because every client will perform the same action.
Instead, event listeners should only be used to update the local state (e.g. a local cache) and send real-time updates to all connected clients, e.g. all browsers listening to websocket events.
If you need to perform actions, for example setting up a first blog post after a new user has been created add it to the service method itself (which will only run on its own instance) or use feather-hooks after hooks.
0.1.0
- Can now use Redis or Mongo
- Initial release
Copyright (c) 2015 David Luecke
Licensed under the MIT license.