Re: Export Go - for preview


Dell - Internal Use - Confidential

Thanks for this Trevor and Drasko,

Good stuff!!!

My top 3 requirements would be:
-Broker-less (we've done MQTT and broker before. It's not a problem, but additional broker requires more setup/containers/etc. and can be large footprint depending on implementation. We can and should still allow MQTT as alternative option for those that want it - like we have been offering in Java side to date - but the default should be brokerless).
-Go native (but also provides libraries for Java, C and possibly other languages). As we look at messaging use between other services in the future, support for polyglot is integral to our tenets and needs of the future.
-Lightweight, ease of use, etc.

What I am seeing on this thread is that people feel Nanomsg may be leading candidate?? Would like to hear from others that have an opinions or questions. I'd like to hold this as a major part of our discussion in the Go project meeting (once we have the mono repo work done).

-----Original Message-----
From: Drasko DRASKOVIC [mailto:drasko@...]
Sent: Friday, February 23, 2018 10:23 AM
To: Conn, Trevor <Trevor_Conn@...>
Cc: White2, James <James_White2@...>; espy <espy@...>; Fede <fclaramonte@...>; dejan.mjc <dejan@...>; edgex-golang@...; manuel@...; Garcia, Gorka <Gorka.Garcia@...>
Subject: Re: [Edgex-golang] Export Go - for preview

Hi Trevor,

On Fri, Feb 23, 2018 at 5:15 PM, <Trevor.Conn@...> wrote:
Dell - Internal Use - Confidential

" If there is an all native Go library for ZMQ, my guys could not find one that works when we looked a few months back."

From what I can see NanoMsg is pitched as the next-gen of ZeroMQ.

There is a Go-native implementation of the NanoMsg scalability protocols called "Mangos"

It appears NanoMsg has clients in a wide variety of languages, though I can't speak to their maturity.
Agreed for Nanomsg, this is a good candidate (btw, I have mentioned this 6 months ago :)).

NATS is interesting too because it's Go native but it would require a server running in a container/natively which either way is another process to manage.
Simplicity. Whole system will be highly simplified, IMHO

I personally don't even see gRPC as a player in the discussion because at the end of the day it's an RPC framework, which seems more suitable if we're talking about replacing REST than a decoupled messaging solution.
Async bi-directional event sending. Protobuf included. Real TLS (because we have HTTP).

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

Twitter: @draskodraskovic

Join to automatically receive all group messages.