Register Custom MessageClient implementations with factory about go-mod-messaging HOT 6 CLOSED

@AlexCuse - I am putting this into backlog (project) and hold status (label) for right now as we are in Hanoi code freeze and I don't want this to get accidentally approved/merged. We'll move it back out and into "in progress" once we get our dashboards setup for the next release.

from go-mod-messaging.

@AlexCuse , what is the use case for this?
I see it useful for custom services that each register a common custom message client and then can pub/sub with each other, but not is the normal Edgex Event flow. I.e. Edgex Core Data wouldn't be publishing messages using the custom message client.

from go-mod-messaging.

I've been primarily using it with messagebus bindings pointing to kafka but planning to test with AMQP and maybe a couple others shortly. Moving mostly towards triggers for this kind of input to our edgex environment, but we have been deploying to some interesting environments where it may make sense to drive the edgex messagebus traffic through existing infrastructure if we want durability.

from go-mod-messaging.

Thinking on it some more I can't really see wanting to publish from core data using this, but I guess why not allow people to build their own that brings in a custom client.

We are typically using this stuff on sort of intermediate northbound compute resources positioned such that they can better interact with a customer's LOB applications etc... so the more options we have for messaging the better. Typically on these machines we will only have application services running, and the last step on our bus out on the gateways is just to facilitate a "track switch" eg from zero to brokers hosted on these resources where the higher level app services can take over processing.

I could see making the custom registration app service only, although with the plan to make core data optional it might be good to have options in the device SDK as well.

from go-mod-messaging.

Another general case that comes to mind I like this for is constructing split clients that connect to different hosts or different protocols all together for publish and subscribe. We have one service that works kind of like a command broadcast - those hub machines connect to the internet and subscribe to a topic on some cloud broker, handle commands locally as needed then place the command on the output which goes to a local MQTT broker that any gateway in the system can have the same service listening to the output topic and act accordingly.

All pretty nonstandard uses and I think some of these cases really are better served by the new triggers. In general I do wonder if the messagebus and messaging triggers could be brought to use the same clients and configuration so that implementing a new client gets you both trigger types but thats a bigger exercise.

from go-mod-messaging.

I'm going to close this for now, since it can do everything the messagebus trigger can and more it likely makes sense to focus on the trigger interface for messaging extensibility. Will see what I can do over there to try and make configuration easier.

from go-mod-messaging.