EMQ vs VerneMQ
Here is the reason why we use EMQ based stack of libraries by Feng Lee instead of MQTT solutions by other vendors.
As you may know, I was creating messaging apps 1) in pure Erlang, I mean storing messages inside Erlang process queues. This simple idea of BEAM usage is well suited for transient in-memory data. However be prepared to reinvent the wheel and build your own PubSub solution. 2) using AMQP and RabbitMQ as a server, however I dislike this because you need to deal with rabbit_common and amqp_client, and with Riak libs that means you will have code clashes, and you need to fork and rehost your rabbit or riak. Also having two applications for simple MQ access seems ridiculous nowadays; 3) now using MQTT which was crafted exactly for lightweight messaging infrastructure.
In the terms of protocols MQTT, is more flexible for transactional messaging that AMQP as it has 3 modes (non-transactional, qos=0, simple acknowledgment, qos=1, and commited transactions, qos=2) and is more simplier that AMQP which becoming a new standard in AWS, Azure and other service providers as main IoT protocol.
The are a lot of options for brokers written in C, the most famous one is Mosquitto, the de-facto standard client is Paho (for all languages), we take a look onto Erlang implementations (Switching data over channels this is what Erlang was created for, right?). The two most notable implementation are Verne from Erlio and EMQ from Feng Lee. Let’s go to their Github: EMQ has over 2K stars, 100 releases, 600 forks, 27 contributors; VerneMQ has over 1K stars, 32 releases, 124 forks, 15 contributors. Internally EMQ implemented as single Erlang application emqttd (which can be used decoupled) but packaged with scripts like standalone product, built with relx. VerneMQ is implemented as a set of applications: vmq_acl, vmq_bridge, vmq_commons, vmq_diversity, vmq_passwd, vmq_plugin, vmq_ql, vmq_server, vmq_webhooks. Most of them are unusable alone and they are not scalable, so I can consider chopping to applications having a developer’s reason. By the declaring features I will show first what is in common.
Both servers stands on solid ground: 3.1/3.1.1 protocol versions, second is needed for offline messages througt inflight window, three levels of QoS (0,1,2), build in Erlang non-blocking TCP servers secured by TLS, WebSocket support, Clustering and Bridging with other MQTT servers in the network.
Now let’s look onto differences: the VerneMQ is stated as built from the ground up, however EMQ is much smaller, yet covering all the features except persistent storage which is implemented in VerneMQ using LevelDB backend. VerneMQ using Graphana to stream events, while EMQ is using its own counters in web admin written in Vue.js. The Database support in VerneMQ is implemented as diversity modules driven by Lua, while in EMQ database backends for auth is implemented as native Erlang modules.
The killer feature of persistent storage is completely missed in EMQ however this could be very easily added which we done inside our Synrc Github organization. Anyway there is very little possibility that LevelDB would stay as the only option in production, so we define an abstraction layer in our fork of EMQ as a KVS backend allowing you in future using all supported databases supported by KVS: Redis, MongoDB, Mnesia, Filesystem, Riak, KAI, PostgreSQL. EMQ has nifty admin which allows you to control all the topics and monitor persisted subscription mesh in real time.
When it comes to build your own infrastructure you usually need tight integration of core services and using MQTT server as standalone product could not be so suitable especially in long term perspective. That is why the sensitive feature is an ability to run as embedded core or as library inside your set of Erlang/OTP applications to have direct access to running processes.
Here are both VerneMQ and EMQ is not so good because they are shipped as standalone products and cutting to library should be done wisely and carefully. However doing so is much simplier for EMQ as it consist of single Erlang/OTP application unlike VerneMQ which is applications bundle.
Such modified version version of EMQ could be built using rebar or mad.
$ brew install erlang
$ curl -fsSL https://raw.github.com/synrc/mad/master/mad > mad \
&& chmod +x mad \
&& sudo cp mad /usr/local/bin
$ git clone git://github.com/voxoz/mq && cd mq
$ mad dep com pla repThe detailed report of customizing MQ build with EMQ as a library is given here: http://ws.n2o.space
Conslusion
The VerneMQ is best when you need persisted messages out of the box, you don’t want to develop internal MQTT features, just download and run your first messaging core. Whenever it comes to custom flexible compact solution you can take more bare bone EMQ which provide also a great support for client libraries: CocoaMQTT, QtMQTT. EMQ shipped with first class benchmarks which could incept a thought that EMQ is a bit faster as it has more native Erlang inside.
