feathers-sync

Feathers sync

Synchronize service events between application instances using Redis or MongoDB publish/subscribe

About

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);

Use with MongoDB:

• 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)

Use with Redis:

• db - The Redis connection string (e.g. redis://localhost:6379) or database object
• connect - A callback for when the Redis connection has been established

Use with AMQP

• 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

How it works

Caveats

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.

Changelog

0.1.0

• Can now use Redis or Mongo
• Initial release

Author

• David Luecke

License

Copyright (c) 2015 David Luecke

Licensed under the MIT license.

Changelog

v0.1.4 (2017-11-11)

Full Changelog

Closed issues:

• Little question i am Missing Something? #68
• An in-range update of redis is breaking the build 🚨 #65
• Node Crashes on user service patch or put requests #63
• Feathers-sync breaks when trying to authenticate #62
• An in-range update of feathers is breaking the build 🚨 #61
• <delete me> #60

Merged pull requests:

• Upgrade to @Feathers v3 #72 (superlazycoder)
• Update debug to the latest version 🚀 #66 (greenkeeper[bot])