Like the idea of feathers-distributed, distribution is actually the key point (by the way I initially wanted to start something with http://nats.io/ or http://nsq.io/). The pun would push something more like feathers-flock or feathers-swarm ;-)
Although the primary purpose of the feathers-sync module is to replicate a similar app I hardly see any limitations to synchronize different apps. I'd like to add that if the only purpose is to scale websockets there is no need to duplicate the running services if a single one can handle the workload. So you could use the module to simply sync a set of "gateways" handling socket requests for a running service instance that performs the "real" work.
So if I understand well you propose to add an abstraction over a messaging system so that we could imagine something similar to REST/Socket:
import amqp from `feathers-amqp`
...
app.configure(amqp({ brokerUrl: xxx }))
What I imagined was adding a similar set of events than the ones that already exist after a service has been called (created, etc.) for service requests (create, etc.). The purpose of the provider modules like feathers-amqp would then be to manage the mapping between incoming/outgoing Feathers events to incoming/outgoing provider messages:
Code would look something like:
amqp.bindOutgoing({
eventIn: 'created', // Optional, defaults to * when just service is given
serviceIn: 'xxx',
topicOut: 'xxx' // Optional, defaults to service name
})
amqp.bindIncoming({
topicIn: 'xxx',
serviceOut: 'xxx' // Optional, defaults to topic name
})
Indeed one purpose of such brokers is also to make newly connected apps react to an existing set of events coming from existing applications.
Then each Feathers app should have its own service registry (ie the app), local/remote services should be callable transparently. The low-level event binding will be used by the services, eg:
// Remote services accept incoming requests from the broker
service.setup = (app, path) => {
amqp.bindIncoming({
topicIn: path,
serviceOut: path
})
}
// Proxy services emit requests to the broker
proxyService.setup = (app, path) => {
amqp.bindOutgoing({
serviceIn: path,
topicOut: path
})
}
The tricky part (v2) would be to also distribute hooks. Indeed because they are first class citizens like services to handle business logic you often face the situation where a module/app wants to push a hook on a service owned by another module/app.
PS Don't know if a client part as mentioned makes sense because most messaging systems already have such client modules, but I probably missed your point.
