Connector for MQTT

[mcqueary]

[drasko]

Big +1 for MQTT support.

Is this on the roadmap?

I am wondering how this can be embedded into NATS? Does it have some kind of pluggable architecture?

@mcqueary can you please provide a few details/description of the idea?

[ColinSullivan1]

@drasko Thank you for your interest! This is something we are gathering requirements about. Could you provide more information about your use case?

[drasko]

@ColinSullivan1 we are currently using NATS in our https://github.com/Mainflux/mainflux project. This is a messaging bridge for IoT.

Devices today connect to cloud via low-overhead protocols like MQTT or CoAP. NATS do not support neither type of connection.

Use-case would be following: http://scn.sap.com/community/pi-and-soa-middleware/blog/2016/02/21/uniting-amqp-and-mqtt-message-brokering-with-rabbitmq

Need that devices connect via MQTT demands the MQTT broker in the system. Since MQTT broker is present, then NATS role is somehow redundant, as pub/sub can be replaced by MQTT broker, and today there are very scalable and performant MQTT brokers. Here is an example of one: http://emqtt.io/ and yet another one: https://vernemq.com/

[kristianmandrup]

We would like to use MQTT / NATS bridge for use with Aither Micro Services

[drasko]

@kristianmandrup this bridge is not so hard to implement and we at Mainflux are using Aedes MQTT broker to bridge it with NATS - take a look here: https://github.com/mainflux/mainflux-mqtt/blob/master/mainflux-mqtt.js

Using this appoach we were able to bridge various protocols, like on the picture here: https://github.com/mainflux/mainflux, and also persist data which is published via NATS and stored into InfluxDB - https://github.com/mainflux/mainflux-influxdb-writer

Having MQTT broker independant from NATS let's you choose your favorite broker. We are currently experimenting with NodeJS and Erlang (https://github.com/mainflux/emqttd-docker) implementations.

[kristianmandrup]

Sweet :)

[iMartyn]

Whilst I agree that having a broker outside of nats is possible, it's also another moving part to go wrong, to monitor and to maintain. +1 for having a native possibility of connecting via mqtt.