Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I had a lot of fun on an embedded systems project recently where I used MQTT as an interprocess messaging system. Broker and clients on the same machine.

If I needed to sniff or debug something it was as easy as putting the device on the network and using MQTT Explorer to record or inject messages. I could even let coworkers that were working remotely work with the system by opening the port outside the LAN.



Haven’t seen this done much but it does seem to have some desirable properties. My biggest concern when using it as a system component has been durability guarantees. I don’t have a lot of trust on broker implementations not to lose data.


> My biggest concern when using it as a system component has been durability guarantees. I don’t have a lot of trust on broker implementations not to lose data

(If we ignore retained messages) MQTT brokers are not designed to store data, so there's no need to be concerned about durability because there simply isn't any...(!)

It is (just) a messaging protocol.


MQTT, by design, isn't going to have the confirmation mechanisms and safeguards that you could get from other methods or even sockets. But once you release yourself from that paranoia, it's pretty liberating.

The nature of my project was that a missed message wouldn't be fatal, and message retention was good enough protection for a process that crashed and restarted.


We use ZeroMQ for this purpose. No broker needed.


this statement is a bit confusing. because with zeromq, one side plays the broker (I dont mean the broker pattern). I mean it in the sense that someone, somewhere, needs to listen on a port. which in the end is the same as having a central mqtt broker sitting somewhere listening on a port. hence the statement "no broker needed" is a bit confusing.


> one side plays the broker

Hopefully most people understand that I meant that you don’t need a stand-alone broker, which on embedded systems means one more thing to deploy and worry about the license for.

Edit: Also:

> The philosophy of ZeroMQ starts with the zero. The zero is for zero broker (ZeroMQ is brokerless)

https://zeromq.org/get-started/


I think you can also connect in a random order, so bind doesn't need to happen before connect.


Would zeromq be an alternative here?


It's an alternative, but there are some aspects to having the broker that I liked. If there was a bug I could halt the system, attach/subscribe an external dev machine, and grab all retained messages from the broker. I don't believe ZMQ allows that.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: