A #VerneMQ customer plans to use more of the stateful features of MQTT/VerneMQ.
So we did a call to discuss QoS, message persistence, shared subscriptions & all that stuff.

All those supposedly simple MQTT features (take QoS) are actually quite complex to users. But I know why and know how to explain them.

@frescosecco We use MQTT in the browser / server communication in #Zotonic. Mostly QoS 0 and 1. It is very cool to see it work in practice. We are kind of amazed nobody seems to use MQTT in a web context.
@maas It's probably the use/usefulness of topics that folks miss. And WebSockets with an ad-hoc small protocol spec does the job for them then.
Cool what you do!
@frescosecco We have a topic tree on the client and one on the server. And we bridge those two. That makes it possible to e.g. Request rendering of a template on the client by publishing a message on the local broker e.g. "bridge/origin/model/template/get/render/_logon_service_error.tpl"
@frescosecco On the server you can communicate with a connected client by publishing to "bridge/<client-id>/". This makes it possible to retrieve something from the client's session or local storage. "bridge/<client-id>/model/get/sessionStorage/<some-key>". The QoS makes it trivial to survive network interruptions (e.g clients navigating). It makes communicating very easy.
@maas Okay, I see! Put MQTT features to work for you.