Re: Export Go - for preview

Drasko DRASKOVIC <drasko@...>

Opened in October 2017:

Mentioned in October on ML:,

Written in this same thread before (unfortunately not sent to the
list) on Feb 19 (5 days ago):

Something we need to eventually revisit - replacing 0MQ with something like Nats or gRPC so that we don't have to do any C compiling and everything is Go. Always more work guys :)
"We have to decide if we want centralized broker or decentralized async
comm like it is today. Both approaches have benfits and drawbacks.
Centralized broker (NATS) would probably simplify the design a lot, as
every service will just send the events to a topic to a known broker
(no need for complicated service discovery), and then whichever
service needs to consume these events will just subscribe to a topic.
On the other hand - it is a SPOF, but this can be solved with FT

ZMQ is a good choice, although that I would personally select nanomsg:, which is a successor of ZMQ (same author). Some
interesting info:,
and there is also Go-native implementation:

gRPC would be probably easier to implement and maintain, but it is
HTTP-based protocol (not TCP, like ZMQ), so some overhead comes with
it. Here is a nice comparison:
I am not sure that in our lightway approach gRPC is better choice than
ZMQ/nanomsg. I expect higher throughput with ZMQ
- although not much higher, since there is just a few clients
connected. I also expect high throughput with NATS, but pure TCP
socket that ZMQ/nanomsg uses is practically unbeatable:

Mainflux Author and Technical Advisor | Industrial IoT Cloud
Engineering Division | Paris, France

Twitter: @draskodraskovic

Join to automatically receive all group messages.