search

rebus-org / Rebus.MongoDb

:bus: MongoDB persistence implementations for Rebus
https://mookid.dk/category/rebus
Other
5 stars 7 forks source link

Please provide some example of how to use this. #10

Closed C0DK closed 2 years ago

C0DK commented 2 years ago

Seems like a great project, but the learning curve is steep.

I have a difficult time figuring out what this does and how to use it. Documentation is none-existing..

mookid8000 commented 2 years ago

Sorry 🙂 Rebus.MongoDb provides persistence implementations for Rebus, and you configure it by going

services.AddRebus(
    configure => configure
        .Transport(...)
        .Sagas(s => s.StoreInMongoDb(...)) //< 1
        .Subscriptions(s => s.StoreInMongoDb(...)) //< 2
        .Timeouts(t => t.StoreInMongoDb(...)) //< 3
);

using either of 1, 2, and/or 3 as you please.

Since this repository is just an integration library, you'll find much more documentation here: https://github.com/rebus-org/Rebus/wiki

C0DK commented 2 years ago

OIC - Could one add a link to the readme that points towards persistence in the Wiki? I cannot find the purpose. Is it just for logging, i.e.? I was thinking of using it for event sourcing, but I cannot determine if this is applicable.

C0DK commented 2 years ago

How can you close this issue? :D The issue hasn't gone away :P

mookid8000 commented 2 years ago

OIC - Could one add a link to the readme that points towards persistence in the Wiki?

I cannot find the purpose. Is it just for logging, i.e.?

No, it's not for logging. Not at all. The package can be used together with Rebus to make Rebus store sagas, subscriptions, and/or timeouts in MongoDB.

Sagas are Rebus' persistent state machines - i.e. persistent objects whose state changes are driven by messages. If you want to read more about sagas, I suggest you go to the Rebus wiki and check out the coordinating things that happen over time scenario.

You also might want to check out this code sample.

Subscriptions are relevant in scenarios where the queue system does not implement publish/subscribe messaging (i.e. routing via topics) natively. In those cases, Rebus can "polyfill" the pub/sub behavior by means of a subscription storage, in this case using MongoDB documents to represent topics and hold the queue names of their subscribers.

Timeouts are "messages sent into the future". Some queueing systems have support for putting a future timestamp on a message when it's sent, which causes the message to be delivered at a later time. Again, Rebus can polyfill this functionality by means of the timeout storage, in this case using MongoDB documents to represent messages to be delivered at a later time.

I was thinking of using it for event sourcing, but I cannot determine if this is applicable.

It's not.

Generally, you should not look towards queues if you want to do anything with event sourcing, because queues are terrible at delivering messages in order, and the order of events is almost always pretty important.