Publishing to RabbitMQ

We are currently in the process of investigating whether we can transition from Jonathan Oliver’s EventStore implementation and as much as much as I would love to use the AtomPub interface we’re currently quite tightly coupled to RabbitMQ as our event publishing and subscribing mechanism.

To minimise the impact of transition I am trying to maintain the Rabbit publishing; looking at SingleNodeWithProjections.Create() it seems that I could implement my own IPublisher and subscribe to the ClientMessage.WriteEvents from the _projectionNode - is this the recommended way of doing it or is there a better way?

Subscribing this way implies configuring and running the EventStore as a bespoke process rather than re-using EventStore.SingleNode other than the additional maintenance effort in keeping up to date is there anything else that we may need to consider?



There are better ways of doing this (and you don't need to custom
host). In about a week there will be a new stream added called $all.
For now you can make your own with a projection if you want.


fromAll().whenAny(function(state,e) {
       linkTo('all', e);
       return state;

Now you can look at all event stream and get all of your events just
like any other event stream.

From client API try SUBSCRIBE ALL .. push to rabbitmq (remember last
you pushed). When you come up query for any missing.



btw: there again will be a $all released in the next week or so that
will be much more performant.

Thanks, finally got it working using the dev branch. If anyone else out there is doing the same thing current master doesn’t seem to work, the EventType and Data properties aren’t being set correctly, all good now on dev.

I have an additional question: Is there a way to get only the ‘application’ events rather than also getting EventStore’s events like $stream-created, $projection-updated, StreamCreated etc. Alternatively is there list of them in the ClientApi so that I can filter them out before trying to deserialize them?



We have been changing them to all start with a $ putting an internal
flag on the event could also be useful. I will add a card for it