Hacker News Reader

Comment by tombert | Hacker News Reader

I've never used Mosquitto, but I have done a fair amount with Verne.mq [1], and I have to say that MQTT is downright pleasant to use in a lot of cases. I've not done a ton with it in "real world" situations, but I have used it for multiple hackathons, and I'm always impressed how little of a headache it is to build a decent "live" application with almost no effort.

If your frontend web project calls for any kind of messaging, I definitely recommend looking into trying MQTT before you jump straight into WebSockets. There's a good chance MQTT does what you need, scales better, can communicate over WebSockets, and will make your life easier .

[1] https://vernemq.com/

View on HN

I have used ZMQ for this with great success. The one-line python calls to send data between nodes are really nice.

ZeroMQ is fantastic. I've been using at work for a few years now, but I generally enjoy the tech anyway, their documentation[0] and "The Guide"[1] is also really nice, with examples for all of the different language bindings.

From C or Golang (or a bunch of other language bindings) you can set up some nice pub/sub or req/res with fan in/fan out and all sorts of cool routing with low-level, high speed sockets with the added power that ZMQ provides, such as the queueing, high-watermarks etc. You can also enable encryption easily with CurveZMQ which is a refreshing change from TLS.

[0]https://zeromq.org/get-started/

[1]https://zguide.zeromq.org/

I almost feel like the guide should be mandatory reading for anyone learning network programming. It gives extremely digestible summaries of most of the network patterns, when and why you'd use them, and then how they're done in ZeroMQ. Even if you end the guide thinking that ZeroMQ is stupid (which you probably wouldn't), you'd still probably benefit from having read the guide.

I love ZeroMQ, but I didn't think that had any first-class support for communicating in the browser (could be wrong).

I agree it's super nice though, even with a single process.

I learned about them on my previous job. It's rather easy to cluster and the Web-Hooks are super easy to get started with. I don't know Erlang myself, but looking at the code and comparing it to some of the Java solutions, it seemed well structured and easier to understand/modify if I wanted to. The only "Issue" I have with it right now, is the "custom OpenSource license" they have.

The VerneMQ bugtracker scares me. Especially this one: https://github.com/vernemq/vernemq/issues/1663. I'm running one instance but I'm on the lookout for an alternative that can more reliably save messages if a subscription client goes down.

I wish I could say that I chose Verne.mq because I weighed all the options and it was the best for my project but...I really chose it because it was written in Erlang and I like Erlang.

I won't pretend to have done an audit of the best servers in terms of bugs or features.

> I definitely recommend looking into trying MQTT before you jump straight into WebSockets.

What is a nice way to use mqtt in the front-end instead of websockets? What can you recommend?

Eclipse Paho JavaScript Client[0] for the front-end and personally I prefer RabbitMQ Web MQTT Plugin[1] for the back-end[1].

Take note Paho MQTT Client is available for several programming languages(Py,Rust,Go,C,C#,etc)[2].

[0]: https://www.eclipse.org/paho/index.php?page=clients/js/index... [1]: https://www.rabbitmq.com/web-mqtt.html [2]: https://www.eclipse.org/paho/index.php?page=downloads.php

Beat me to it!

I was about to suggest the Eclipse Paho library. One of the very few things in the developer world that has "just worked" for me the first time I tried it.

Yeah, it's pretty cool. I am tasked with developing a new API and communication method for a bunch of networked devices that run embedded Linux. Initially I focused on MQTT, but have since decided to define an API in OpenAPI and implement an HTTP/REST-style interface because that's well understood and easily supported by third parties, whose APIs we might want to integrate with or provide a translation layer for.

But the devices need to alert a controller application to status changes... which so far I supposed they would do by POSTing REST-style messages back to that application. Do people combine REST & MQTT?

> Do people combine REST & MQTT?

I'm not a REST+MQTT expert, but some people do combine them, why not?

One of the project I was working on (IoT, smart home), the mobile app received the current status from the REST API, then subscribed to changes via MQTT. Having MQTT was great for live updates on the mobile app, and for communicating with the IoT devices. HTTP was great for integrations with Google Home, Alexa, and we could test it easily as there are many backend frameworks focusing on CRUD REST HTTP backend apps.

Of course, if you actually have a problem you want to solve, be sure the to do your own research, there are more than one way to skin a cat, and there are so many services and platforms that could be "good enough" for your use case.

Generally people choose MQTT because it is lightweight and very well tested. I personally use it because its light one source, scalable, and very flexible. Have also chosen to use CoAP rather than REST for ad hoc data requests because for constrained devices it is much lighter on bandwidth, simpler to use than typical REST over TCP+HTTP with which most people are familiar.

In IOT its hard to go past MQTT for the usual signals paired with CoAP for ad hoc. When I want to reduce dependencies or just being lazy even CoAP gets replaced with building a request/respond mechanism using a MQTT queue so a hub pubs a message to the devices command queue and device reads that queue and responds to it. How often device checks the command queue depends on whether or not device can run command queue monitoring asynchronously or must do a scheduled round-robin of the queues.

The Eclipse Paho libs have been great for me using across different OS and bare metal, Arduino, FreeRTOS.

One thing to note is that MQTT is session-oriented, so you have to send periodic pings to the server to keep your session active. Which is obviously a deviation from stateless REST.

The REST paper explicitly mentions that REST and HTTP only try to solve the common cases, and solve those well. If something is not covered well then you’re explicitly advised to leave it to another protocol. You could for example have a GET response that (due to HATEOAS) suggests a websocket url including a topic to subscribe to.

Reply on news.ycombinator.com