3 ms·

I would like to point out that there exists solutions tested in the field in the last 20 years to solve the same problem. In particular I would suggest to get

by siscia 8y ago

I would like to point out that there exists solutions tested in the field in the last 20 years to solve the same problem. In particular I would suggest to get to know MQTT an open protocol with several (open and close) implementation that is know for its flexibility and scalability (if nothing has changed it is used to power the Messager Facebook platform, but don't quote me on that). verneMQ is the server implementation I would suggest if you are interested in such topic.

qwertox 8y ago
MQTT is just a protocol, not a service. I don't think it was the developer's intention to provide an alternative to MQTT, but to offer a solution for push-notifications, which just happens to be built on top of WebSocket without MQTT. Also keep in mind that MQTT will usually get wrapped by WebSocket to avoid issues with firewalls or to easily get TLS via a proxy server like NGINX, or simply to add web browser support. VerneMQ is not the only server implementation for MQTT.
- siscia 8y ago
  Really, what your comments add to the discussion? You just re-phrased everything I said in a more negative tone with zero value added. I said myself that MQTT is a protocol and again I said that verneMQ is an implementation of the broker, the one that I suggest but not the only one. And yes, it was a choice to leave aside the implementation detail of the use of websockets for MQTT because is a different level of abstraction. Please let's try to add value to the community and not just add noise and entropy. Before to comment I asked myself. 1) does this need to be said? And since people where finding this project interesting I decided that yes, the same people could be interested in knowing another more mature ecosystem that target a similar niche. 2) does this need to be said by me? And again, yes, none mentioned it already, the post was up for a while and I do have production experience with MQTT. Please try to follow the same guidelines!
  - d76d6776yudsy 8y ago
    Blah bleh bluh
  - qwertox 8y ago
    My apologies on the VerneMQ comment. I misread the sentence, not realizing it being a specific suggestion by you. Regarding the topic of MQTT in general, to me it sounded as if you were not adding information but criticizing the choice of WebSocket instead of MQTT in this project. It was a misunderstanding. To add to the discussion, maybe you could help me a bit with an issue I'm having. I'm currently working on a service which is starting to make use of MQTT for microservices communication. Initially I was using a WebSocket server for this, then moved over to RabbitMQ a couple of years ago, and now I have added a Mosquitto server which is working, but has not yet replaced RabbitMQ. This service also has one public NodeJS websocket server for web browser clients to connect to it, this WebSocket server receives the messages via RabbitMQ and dispatches it to the clients. I also want to replace that WebSocket server by another Mosquitto instance, so that MQTT will basically become the main way for communication between servers and also with clients. I chose Mosquitto because it have been using it at home without any problems for a while now and have a custom authentication plug-in for it which I wanted to reuse. VerneMQ is a candidate, but Mosquitto is working just fine, so I haven't looked into it again. I like how lean Mosquitto is and how it's configured inside a container. Plus I can understand the source code and eventually modify it. Would you advise me against using Mosquitto in a production system? Which benefit would I have by using VerneMQ? My apologies, again.
    - siscia 8y ago
      Don't worry! We are all busy and sometimes is normal to read too quickly a message on internet. My advice would be to have one single broker no matter what, so don't replace the websockets server with another instace of mosquitto, but just use the same old instance. Then, the ice thing of working with a protocol is that you don't care of the implementation, hence just keep using mosquitto until it support the load and the, eventually swap verneMQ if necessary. Be careful with your custom authentication logic, that if you want to migrate will require you to port it over. Verne provide plugins for Auth so it is not an huge deal but you need to think a little bit ahead. But again, if mosquitto is working fine just keep it! Cheers!
lmorchard 8y ago
Depends on the exact problem definition. This is a small, single-binary server, offering a built-in web UI & API, requiring very little configuration, working with a mobile app for Android phones. Took me 5 minutes to start getting some notifications from things around my house. Sometimes you don't need a cargo van or a jumbo jet to get the job done when a skateboard will do.

by siscia 8y ago

qwertox 8y ago

MQTT is just a protocol, not a service. I don't think it was the developer's intention to provide an alternative to MQTT, but to offer a solution for push-notifications, which just happens to be built on top of WebSocket without MQTT. Also keep in mind that MQTT will usually get wrapped by WebSocket to avoid issues with firewalls or to easily get TLS via a proxy server like NGINX, or simply to add web browser support. VerneMQ is not the only server implementation for MQTT.

siscia 8y ago
Really, what your comments add to the discussion? You just re-phrased everything I said in a more negative tone with zero value added. I said myself that MQTT is a protocol and again I said that verneMQ is an implementation of the broker, the one that I suggest but not the only one. And yes, it was a choice to leave aside the implementation detail of the use of websockets for MQTT because is a different level of abstraction. Please let's try to add value to the community and not just add noise and entropy. Before to comment I asked myself. 1) does this need to be said? And since people where finding this project interesting I decided that yes, the same people could be interested in knowing another more mature ecosystem that target a similar niche. 2) does this need to be said by me? And again, yes, none mentioned it already, the post was up for a while and I do have production experience with MQTT. Please try to follow the same guidelines!
- d76d6776yudsy 8y ago
  Blah bleh bluh
- qwertox 8y ago
  My apologies on the VerneMQ comment. I misread the sentence, not realizing it being a specific suggestion by you. Regarding the topic of MQTT in general, to me it sounded as if you were not adding information but criticizing the choice of WebSocket instead of MQTT in this project. It was a misunderstanding. To add to the discussion, maybe you could help me a bit with an issue I'm having. I'm currently working on a service which is starting to make use of MQTT for microservices communication. Initially I was using a WebSocket server for this, then moved over to RabbitMQ a couple of years ago, and now I have added a Mosquitto server which is working, but has not yet replaced RabbitMQ. This service also has one public NodeJS websocket server for web browser clients to connect to it, this WebSocket server receives the messages via RabbitMQ and dispatches it to the clients. I also want to replace that WebSocket server by another Mosquitto instance, so that MQTT will basically become the main way for communication between servers and also with clients. I chose Mosquitto because it have been using it at home without any problems for a while now and have a custom authentication plug-in for it which I wanted to reuse. VerneMQ is a candidate, but Mosquitto is working just fine, so I haven't looked into it again. I like how lean Mosquitto is and how it's configured inside a container. Plus I can understand the source code and eventually modify it. Would you advise me against using Mosquitto in a production system? Which benefit would I have by using VerneMQ? My apologies, again.
  - siscia 8y ago
    Don't worry! We are all busy and sometimes is normal to read too quickly a message on internet. My advice would be to have one single broker no matter what, so don't replace the websockets server with another instace of mosquitto, but just use the same old instance. Then, the ice thing of working with a protocol is that you don't care of the implementation, hence just keep using mosquitto until it support the load and the, eventually swap verneMQ if necessary. Be careful with your custom authentication logic, that if you want to migrate will require you to port it over. Verne provide plugins for Auth so it is not an huge deal but you need to think a little bit ahead. But again, if mosquitto is working fine just keep it! Cheers!

lmorchard 8y ago

Depends on the exact problem definition. This is a small, single-binary server, offering a built-in web UI & API, requiring very little configuration, working with a mobile app for Android phones. Took me 5 minutes to start getting some notifications from things around my house. Sometimes you don't need a cargo van or a jumbo jet to get the job done when a skateboard will do.