Subscribing Multiple Topics, using wildcards or creating instances? - node.js

Question

I am currently in the middle of a project which include the use of MQTT. I'm writing my application in node.js. My project requires to connect/communicate to multiple devices which each device has specified and different topic(s). Later, the data from the each message will be stored into database (MongoDB). I'm using mqtt package from npmjs.com 1.
Below is an example of mqtt package code:
var mqtt = require('mqtt');
var client = mqtt.connect('mqtt://test.mosquitto.org');
client.on('connect', function () {
client.subscribe('presence');
client.publish('presence', 'Hello mqtt');
});
client.on('message', function (topic, message) {
// message is Buffer
console.log(message.toString());
client.end();
});
My problem is what should I do to get messages from the devices. I can easily list to a single topic using "#" to get all topics but I have to manually sort/split the topic and etc.
However, I'm thinking of another option in which I will create new mqtt client instance for each topic but I do not know if there is any limit of instances. I might use forever function from async package 2. My code might be like this:
var async = require('async');
var mqtt = require('mqtt');
var client = mqtt.connect("URL of MQTT broker");
var _topic = "";
var Subscriber = function(topic){
this._topic = topic;
client.on('connect', function () {
client.subscribe(this.topic.setter);
});
async.forever(
function(next){
client.on('message', function (topic, message) {
// TO DO store message
});
},
function(err){
client.end();
}
);
};
module.exports = Subscriber;
Does anyone have any recommendation?

Answer 1

I would not recommend creating a separate connection for each subscription you want to make. Each connection is a new TCP connection and would waste resources in both your application and the broker.
The normal pattern here would be to use a wildcard subscription. The message callback handler is handed the topic the message came on, so, as long as your sensibly structure your topic space, there is very little overhead in having to route the message appropriately in your application.