Channels are producer/consumer queues, they don't handle one to many broadcasting, you'd need one channel per subscriber then you'd queue the message to each of them. In my opinion, they work more nicely than callbacks, since your handler can run in its own execution context, and not in the callback invoker's execution context. They are really nice for round robin between multiple receivers, though.
Why write it yourself? Check out the Go bindings for Zeromq <http://zeromq.org/bindings:go>, which supports pub-sub in exactly the way you mention. I've used this thing in production to route > 200,000 pub/sub messages per second. It may be overkill if you're within a single process, though. -- Marcin On Sun, Mar 10, 2019 at 9:41 PM Kasun Vithanage <alanka...@gmail.com> wrote: > Hi all, > > I've experience implementing event buses in Java. > In Java, I used a singleton where I can register callbacks to methods and > fire event from a publisher(maybe from another thread) and propagate it to > subscribers. > > In Go what would be the best pattern to implement a pub/sub event bus? > Are channels are a better choice than using callbacks in this scenario(*one > to many* event propagation)? > Or callbacks are better for this? > > (I need to propagate events *only* to subscribers of the topic) > > Regards, > Kasun > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
