A distributed, tag-based pub-sub service for modern web applications
github.com
github.com
I'm most interested in:
[Hooky D](https://github.com/nanopack/hookyd) - Remote hook execution layer
[Butter](https://github.com/nanopack/butter) - Git based deployment system
[Shuttle](https://github.com/nanopack/shuttle) - Transparent TCP proxy for webThe erlang version has been running successfully for about 2 years and we haven't had any issues whatsoever (excepting a wrestling match with mnesia early on). We are erlang/elixir advocates and have used the erlang vm successfully on highly critical multi-million-concurrency services for over 6 years.
When we set out to build nanobox desktop (https://desktop.nanobox.io) our vision was to provide a single pre-compiled executable that could be run without any configuration. The design required a push layer and needed the same functionality that the erlang project was already providing. It wasn't feasible to package the erlang application into the nanobox binary, so we emulated the original project into a consumable golang package. As time went on we were porting more and more of the features into the golang port until all that was lacking was distribution and authentication. At that point we made the decision to consolidate our efforts into a single project, that could be a standalone service or composed within a golang binary.
I regret to inform you that there isn't a mass exodus within our company to ditch erlang for golang. While that certainly would make for a fun thread, in this case it was simply a matter of fit and effort consolidation.
"Data flowing through mist is NOT touched in anyway. It is not verified in any way, but it MUST NOT contain a newline character as this will break the mist protocol."
I haven't read the code yet, but my gut reaction is that this suggests it would be possible to inject commands using malicious user input. Given the caveat, this may be allowed for by your threat model, but it may be worth some effort to mitigate.
EDIT: To clarify, this may not be the case at all, in which case I'd be curious to hear why this restriction is in place.
Currently the public-facing websocket client is not allowed to publish messages until this is mitigated, as you mentioned. Any feedback here would be appreciated.
RIFF is a bit better https://en.wikipedia.org/wiki/Resource_Interchange_File_Form... with strict length,tag,contents format.
> Messages are not stored until they are delivered, if no client is available to receive the message, then it is dropped without being sent anywhere.
Not sure in which use cases can I use this ? Doesn't this defeat the purpose of having a message queue.
As to the second, the caveat is basically saying that if a message is broadcast and nobody cares about the message (ie: there aren't any subscriptions) then mist isn't going to store the message anywhere, it just gets dropped.
Similar to the old question, "if a tree falls in the woods and no one is there to hear it does it make a sound?" Yes; similarly Mist will send a message whether or not anyone is listening, and will keep sending them whether or not the client is prepared to handle them.
That makes is okay for things like realtime dashboards (which this is apparently designed for) and other rapid events where transactionality is not required.
But it's obviously not suited for job-like scheduling like data processing or email delivery. Nor as an event bus for inter-service coordination ("on event X, do Y").
I would also say that gnats is mature and has been proven in production for several years, which might not be the case with this project.
Any chance of basing it on `igm/sockjs-go` or similar instead of raw websockets?
Propagating events is really simple: When a client subscribes to a particular node, the node will replicate the subscription to all nodes in the cluster, and relay any messages from the 'proxied' subscriptions back to the client.