4 ms·

Show HN: Msngr.js, a messaging library for JavaScript

32 points by BinaryIdiot 12y ago

BinaryIdiot 12y ago
I started working on this small library some time ago and use it in many of my personal projects. It’s not meant to replace any existing libraries (though you could certainly use it to replace some things here and there) but to augment by using messaging. I use this quite frequently when I work with web components where I try to make my messages as generic as possible so I can separate my UI from my business logic completely. Not sure if others will find it useful but figured I’d see what feedback hacker news would have, if any :)
- pcthrowaway 12y ago
  Hi, thanks for sharing. I'm fairly inexperienced with using any kind of message-based event management so my question may reveal a deficit in understanding on my part: Would something like this be a javascript-runtime environment translation of message brokering libraries like ZeroMQ and RabbitMQ? If so, does that mean an application that already utilizes a messaging library such as those two could plug in msngr.js on the client or server-side (if using node) and use messages received from the message broker more directly, instead of having to translate them into emitted events?
  - BinaryIdiot 12y ago
    So msngr.js currently only works within your current process (so a web page or a node app) and is meant to help organize code and interface with internally, and externally, developed components. I do hope to eventually interface it with other brokering libraries but since it's a small, pet project of mine that's a bit far off I think.
prottmann 12y ago
What is the benefit of msngr compared to other pub/sub libraries like AmplifyJS (https://github.com/appendto/amplify https://github.com/appendto/amplify) or Postal (https://github.com/postaljs/postal.js https://github.com/postaljs/postal.js). Both of them are battle tested and have a big community.
- currywurst 12y ago
  One of the doubts I had was how these 'broker' approaches are better than basic Event emitters, and Postal has a nice section : https://github.com/postaljs/postal.js#why-would-i-use-it https://github.com/postaljs/postal.js#why-would-i-use-it
- jonobird1 12y ago
  I'd also like to hear this. pub/sub libraries already work pretty great so how do you differ from this?
- jbob2000 12y ago
  We moved away from the pub/sub model in our app. It became too difficult to manage all the pub subs happening across modules, especially in a large project with many team members. We're restructuring our app to be better organized and to use a live-binding library.
  - currywurst 12y ago
    I'm really interested in how this model scales, so could you please explain a bit what was difficult to manage in pub/sub ? I would imagine that if your topics and channels are well-defined and documented in one place, and the modules also declare what topics they pub/sub, one would get clear boundaries for maintenance. Also, what do you mean by live-binding ?
    - jbob2000 12y ago
      > if your topics and channels are well-defined and documented in one place That's the problem. It's hard to get this done. Developers like to develop, it's like pulling teeth to get us to document things. I've found its much easier and faster to have a codebase that speaks-for-itself, in a way. Don't get me wrong, we definitely do document things. But the miniscule things like implementation details are just too small to be worth spending time on. We've been in production for about 7 years now. Our team has pretty much completely turned over in that time. Knowledge and conventions get lost, much better to have the codebase dictate how things should be done. A developer will read the code+comments before they read the documentation. Hmm how to explain live-binding... Angular's $scope and CanJS' Observables are examples of live-binding. Basically, you can pass around a live-binding object and changes made to it in one module are immediately reflected in another. Whereas with a pub/sub model, you publish messages out to a hub and it is up to the module to decide how to react to the message. A good example of how we use live-binding is with sessions. We have a global live-bound object that holds the session data. Each module that needs to use session info simply refers to this global object. If we perform an API call that returns 401 and kills the session, our API module kills the session object and all our modules immediately respond to this change. We don't have to declare any listeners, or subscribe to any pubs; we just use the object.
Mahn 12y ago
What problem does this solve? Can't you just simply declare the "loosely coupled" methods as functions and call them wherever needed in vanilla javascript? Perhaps I'm missing something but judging by the examples, and assuming the messages are local to a particular process, I don't see why would you do this: msngr.register({ topic: "Save", category: "Profile", dataType: "application/json" }, function (payload) { console.log("Save profile information here"); }); msngr.emit({ topic: "Save", category: "Profile", dataType: "application/json" }, { name: "Kris", country: "United States" }); Rather than: function saveProfile(payload) { console.log("Save profile information here"); } saveProfile({ name: "Kris", country: "United States" });
- michael_fine 12y ago
  The examples don't illustrate this very well, but the benefit of message passing is flexibility/decentralization of events. To use your example, if when you saved the profile you wanted to also pass it to an internal analytics database, makes more organizational sense to have that database just register a listener for a save profile event, rather than having to add a very auxiliary step within the saveProfile function. This gets more and more helpful the more listeners you have, and while I haven't looked at this library in depth, can also be a very natural way of writing async code.
- BinaryIdiot 12y ago
  I wish I had some examples in my repo (still considering this more of a beta so I'll get to it eventually) but the big thing for me is the separation with descriptive meta data. The idea behind this is so you can create message receivers that can respond to a variety of items without even knowing the origin. Much like Android intents where intents can come from internally or externally these messages can be handled the same way (hence my primary use case is using them with web components; I can make a web component publish specific messages and have my business logic handle them without ever touching anything in the UI layer). I started working on an experiment where I wrote two controllers that handled the UI with msngr.bind(), one for a web browser and one for a native application using node-qt (which is basically a dead project now and one of the reasons I never finished my experiment but I digress). The business logic never had to chance at all but the controllers could be swapped. It's not hugely different than your example but I like the separation and descriptiveness it gives me. I also have plans to eventually revisit old code I have written where messages can cross web browser windows and the client-server boundary but not sure when I'll get to that. Hope that helps!

32 points by BinaryIdiot 12y ago

I started working on this small library some time ago and use it in many of my personal projects. It’s not meant to replace any existing libraries (though you could certainly use it to replace some things here and there) but to augment by using messaging. I use this quite frequently when I work with web components where I try to make my messages as generic as possible so I can separate my UI from my business logic completely. Not sure if others will find it useful but figured I’d see what feedback hacker news would have, if any :)

pcthrowaway 12y ago
Hi, thanks for sharing. I'm fairly inexperienced with using any kind of message-based event management so my question may reveal a deficit in understanding on my part: Would something like this be a javascript-runtime environment translation of message brokering libraries like ZeroMQ and RabbitMQ? If so, does that mean an application that already utilizes a messaging library such as those two could plug in msngr.js on the client or server-side (if using node) and use messages received from the message broker more directly, instead of having to translate them into emitted events?
- BinaryIdiot 12y ago
  So msngr.js currently only works within your current process (so a web page or a node app) and is meant to help organize code and interface with internally, and externally, developed components. I do hope to eventually interface it with other brokering libraries but since it's a small, pet project of mine that's a bit far off I think.

prottmann 12y ago

What is the benefit of msngr compared to other pub/sub libraries like AmplifyJS (https://github.com/appendto/amplify https://github.com/appendto/amplify) or Postal (https://github.com/postaljs/postal.js https://github.com/postaljs/postal.js). Both of them are battle tested and have a big community.

currywurst 12y ago
One of the doubts I had was how these 'broker' approaches are better than basic Event emitters, and Postal has a nice section : https://github.com/postaljs/postal.js#why-would-i-use-it https://github.com/postaljs/postal.js#why-would-i-use-it
jonobird1 12y ago
I'd also like to hear this. pub/sub libraries already work pretty great so how do you differ from this?
jbob2000 12y ago
We moved away from the pub/sub model in our app. It became too difficult to manage all the pub subs happening across modules, especially in a large project with many team members. We're restructuring our app to be better organized and to use a live-binding library.
- currywurst 12y ago
  I'm really interested in how this model scales, so could you please explain a bit what was difficult to manage in pub/sub ? I would imagine that if your topics and channels are well-defined and documented in one place, and the modules also declare what topics they pub/sub, one would get clear boundaries for maintenance. Also, what do you mean by live-binding ?
  - jbob2000 12y ago
    > if your topics and channels are well-defined and documented in one place That's the problem. It's hard to get this done. Developers like to develop, it's like pulling teeth to get us to document things. I've found its much easier and faster to have a codebase that speaks-for-itself, in a way. Don't get me wrong, we definitely do document things. But the miniscule things like implementation details are just too small to be worth spending time on. We've been in production for about 7 years now. Our team has pretty much completely turned over in that time. Knowledge and conventions get lost, much better to have the codebase dictate how things should be done. A developer will read the code+comments before they read the documentation. Hmm how to explain live-binding... Angular's $scope and CanJS' Observables are examples of live-binding. Basically, you can pass around a live-binding object and changes made to it in one module are immediately reflected in another. Whereas with a pub/sub model, you publish messages out to a hub and it is up to the module to decide how to react to the message. A good example of how we use live-binding is with sessions. We have a global live-bound object that holds the session data. Each module that needs to use session info simply refers to this global object. If we perform an API call that returns 401 and kills the session, our API module kills the session object and all our modules immediately respond to this change. We don't have to declare any listeners, or subscribe to any pubs; we just use the object.

Mahn 12y ago

What problem does this solve? Can't you just simply declare the "loosely coupled" methods as functions and call them wherever needed in vanilla javascript? Perhaps I'm missing something but judging by the examples, and assuming the messages are local to a particular process, I don't see why would you do this: msngr.register({ topic: "Save", category: "Profile", dataType: "application/json" }, function (payload) { console.log("Save profile information here"); }); msngr.emit({ topic: "Save", category: "Profile", dataType: "application/json" }, { name: "Kris", country: "United States" }); Rather than: function saveProfile(payload) { console.log("Save profile information here"); } saveProfile({ name: "Kris", country: "United States" });

michael_fine 12y ago
The examples don't illustrate this very well, but the benefit of message passing is flexibility/decentralization of events. To use your example, if when you saved the profile you wanted to also pass it to an internal analytics database, makes more organizational sense to have that database just register a listener for a save profile event, rather than having to add a very auxiliary step within the saveProfile function. This gets more and more helpful the more listeners you have, and while I haven't looked at this library in depth, can also be a very natural way of writing async code.
BinaryIdiot 12y ago
I wish I had some examples in my repo (still considering this more of a beta so I'll get to it eventually) but the big thing for me is the separation with descriptive meta data. The idea behind this is so you can create message receivers that can respond to a variety of items without even knowing the origin. Much like Android intents where intents can come from internally or externally these messages can be handled the same way (hence my primary use case is using them with web components; I can make a web component publish specific messages and have my business logic handle them without ever touching anything in the UI layer). I started working on an experiment where I wrote two controllers that handled the UI with msngr.bind(), one for a web browser and one for a native application using node-qt (which is basically a dead project now and one of the reasons I never finished my experiment but I digress). The business logic never had to chance at all but the controllers could be swapped. It's not hugely different than your example but I like the separation and descriptiveness it gives me. I also have plans to eventually revisit old code I have written where messages can cross web browser windows and the client-server boundary but not sure when I'll get to that. Hope that helps!