[LRUG] Event Bus in ruby

Thu Aug 21 03:49:49 PDT 2014

If its of any interest to anyone this is what I have done with eventbus in
Be My Eyes so far
https://github.com/bemyeyes/bemyeyes-server/tree/feature/eventbus

Med Venlig hilsen / Best regards

Klaus Hebsgaard

Website: http://www.hebsgaard.dk
Blog: *http://blog.khebbie.dk <http://blog.khebbie.dk>*
LinkedIIn: http://www.linkedin.com/in/klaushebsgaard
Github: https://github.com/khebbie

On Wed, Aug 20, 2014 at 2:04 PM, Klaus Hebsgaard <klaus at hebsgaard.dk> wrote:

> Yes, EventBus it the one I ended up with.
> Seems pretty solid, and since Paul Robinson gave a thumbs up for the
> author that makes me trust it more.
>
> The only problem I have is that EventBus is meant to be used in a static
> fasion which makes unit testing a bit harder, but not impossible...
>
> Med Venlig hilsen / Best regards
>
> Klaus Hebsgaard
>
> Website: http://www.hebsgaard.dk
> Blog: *http://blog.khebbie.dk <http://blog.khebbie.dk>*
> LinkedIIn: http://www.linkedin.com/in/klaushebsgaard
> Github: https://github.com/khebbie
>
>
> On Wed, Aug 20, 2014 at 1:38 PM, Stephen Best <bestie at gmail.com> wrote:
>
>> Klaus I think you answered your own question with "implement a simple
>> observer pattern". Synchronous pub/sub is trivial to implement with plain
>> old Ruby objects with this approach offering the best in terms of
>> decoupling.
>>
>> Applied correctly it should be very easy to later swap out your event
>> consumers for objects that put jobs onto asynchronous queues.
>>
>> Wisper seems to encourage users to have domain or ActiveRecord objects
>> emit events which I find a bit distasteful.
>>
>> EventBus seems like a much better option if you'd rather use a library.
>>
>> Bestie.
>>
>> theaudaciouscodeexperiment.com
>> github.com/bestie
>> @thebestie
>>
>>
>> On 20 August 2014 12:15, Klaus Hebsgaard <klaus at hebsgaard.dk> wrote:
>>
>>> Thank you everyone who gave suggestions
>>>
>>> Med Venlig hilsen / Best regards
>>>
>>> Klaus Hebsgaard
>>>
>>> Website: http://www.hebsgaard.dk
>>> Blog: *http://blog.khebbie.dk <http://blog.khebbie.dk>*
>>> LinkedIIn: http://www.linkedin.com/in/klaushebsgaard
>>> Github: https://github.com/khebbie
>>>
>>>
>>> On Wed, Aug 20, 2014 at 12:41 PM, James Pike <lrug at chilon.net> wrote:
>>>
>>>> The awkward thing about Redis is you only get a single "watch" per TCP
>>>> connection, with the exception of pub sub (which puts your connection
>>>> into "subscriber mode" and limits it to only pub/sub operations). If you
>>>> only want to stick to pubsub then it's cool, but then if you are tempted
>>>> by other things like queues and hashes and operations to watch them,
>>>> then you have to start having to spawn multiple TCP connections for each
>>>> watch operation, and then writing connection pools etc. That makes me
>>>> sad.
>>>>
>>>> RabbitMQ is nice in that you can consume all its goods with a single TCP
>>>> connection.
>>>>
>>>> Cheers, James
>>>>
>>>> On Wed, Aug 20, 2014 at 11:14:12am +0100, Sleepyfox wrote:
>>>> > Something that might initially sound a bit weird, but suits small apps
>>>> > well, is using Redis for it's dirt simple Pub/Sub support. It's
>>>> > trivially easy to use Redis as a message bus (trivially easy to use
>>>> > Redis, full stop), and if you're not looking for the last word in
>>>> > sophistication or scale (in which case something like RabbitMQ is
>>>> > probably a better bet) it does the job.
>>>> >
>>>> > The approach is described in the following article (about Node rather
>>>> > than Ruby, but you get the picture):
>>>> >
>>>> > Fox
>>>> > --
>>>> > "What does the @sleepyfox say?"
>>>> >
>>>> >
>>>> > On 20 August 2014 09:23, Klaus Hebsgaard <klaus at hebsgaard.dk> wrote:
>>>> > > Thanks for the pointer, however there were a few points I didn't
>>>> put into
>>>> > > the original request:
>>>> > > - I need something small, as the app is small
>>>> > > - I don't mind synchronous event busses, as we don't handle
>>>> anything big
>>>> > > yet.
>>>> > > - I would like some simplicity, so adding more processes to run on
>>>> the
>>>> > > server, would be too much overhead at the moment
>>>> > > - We use MRI at the moment, though I can see lots of advantages to
>>>> JRuby
>>>> > >
>>>> > >
>>>> > >
>>>> > > Med Venlig hilsen / Best regards
>>>> > >
>>>> > > Klaus Hebsgaard
>>>> > >
>>>> > > Website: http://www.hebsgaard.dk
>>>> > > Blog: http://blog.khebbie.dk
>>>> > > LinkedIIn: http://www.linkedin.com/in/klaushebsgaard
>>>> > > Github: https://github.com/khebbie
>>>> > >
>>>> > >
>>>> > > On Wed, Aug 20, 2014 at 9:38 AM, Vish Vishvanath <
>>>> vish.vishvanath at gmail.com>
>>>> > > wrote:
>>>> > >>
>>>> > >> Hey Klaus,
>>>> > >>
>>>> > >> On a slightly different note, I've had very positive experiences
>>>> with Ruby
>>>> > >> in vert.x,  which enables excellent decoupling with its system of
>>>> > >> 'verticles': independent code modules communicating via immutable
>>>> primitives
>>>> > >> across an event bus.
>>>> > >>
>>>> > >> The fact that you can leverage Java and several languages in the
>>>> same
>>>> > >> codebase is a bonus.
>>>> > >>
>>>> > >> Best
>>>> > >>
>>>> > >> vv
>>>> > >>
>>>> > >> On 20 Aug 2014, at 07:42, Klaus Hebsgaard <klaus at hebsgaard.dk>
>>>> wrote:
>>>> > >>
>>>> > >> Hello
>>>> > >>
>>>> > >> I am currently looking into decoupling my app a bit more.
>>>> > >> Coming from a C# background I would like to use an Event Bus for
>>>> this, so
>>>> > >> that I can apply the observer pattern.
>>>> > >>
>>>> > >> I have searched a bit around and have found:
>>>> > >> https://github.com/kevinrutherford/event_bus
>>>> > >>
>>>> > >> Does anyone know this gem, is it worth using (well maintained etc)?
>>>> > >> Do you know of good alternatives?
>>>> > >>
>>>> > >> Med Venlig hilsen / Best regards
>>>> > >>
>>>> > >> Klaus Hebsgaard
>>>> > >>
>>>> > >> Website: http://www.hebsgaard.dk
>>>> > >> Blog: http://blog.khebbie.dk
>>>> > >> LinkedIIn: http://www.linkedin.com/in/klaushebsgaard
>>>> > >> Github: https://github.com/khebbie
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> Chat mailing list
>>>> > >> Chat at lists.lrug.org
>>>> > >> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>>> > >> Manage your subscription:
>>>> http://lists.lrug.org/options.cgi/chat-lrug.org
>>>> > >> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>> > >
>>>> > >
>>>> > >
>>>> > > _______________________________________________
>>>> > > Chat mailing list
>>>> > > Chat at lists.lrug.org
>>>> > > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>>> > > Manage your subscription:
>>>> http://lists.lrug.org/options.cgi/chat-lrug.org
>>>> > > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>> > >
>>>> > _______________________________________________
>>>> > Chat mailing list
>>>> > Chat at lists.lrug.org
>>>> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>>> > Manage your subscription:
>>>> http://lists.lrug.org/options.cgi/chat-lrug.org
>>>> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>>
>>>> --
>>>> http://chilon.net
>>>>
>>>
>>>
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>> Manage your subscription:
>>> http://lists.lrug.org/options.cgi/chat-lrug.org
>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140821/a5b9888f/attachment-0003.html>