Re: Export Go - for preview

Drasko DRASKOVIC <drasko@...>
 

Opened in October 2017: https://github.com/drasko/edgex-export/issues/10

Mentioned in October on ML:
https://lists.edgexfoundry.org/pipermail/edgex-golang/2017-October/000006.html,
https://lists.edgexfoundry.org/pipermail/edgex-golang/2017-October/000004.html

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
deployment.

ZMQ is a good choice, although that I would personally select nanomsg:
http://nanomsg.org/, which is a successor of ZMQ (same author). Some
interesting info:
https://bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/,
and there is also Go-native implementation:
https://github.com/go-mangos/mangos.

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:
https://stackoverflow.com/questions/39350681/grpc-and-zeromq-comparsion.
I am not sure that in our lightway approach gRPC is better choice than
ZMQ/nanomsg. I expect higher throughput with ZMQ
(https://bbengfort.github.io/observations/2017/09/04/message-throughput.html)
- 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:
https://bravenewgeek.com/dissecting-message-queues/
"

BR,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Join EdgeX-GoLang@lists.edgexfoundry.org to automatically receive all group messages.