2

i came late to the messaging party so I am a little confused on this simple scenario. I have a website with a feedback form and when the user sends their feedback my business requirements state I need to persist the feedback for reporting purposes, send an email to the product manager, and send a thank you email to the sender.

now i see a few different options:

  1. The web server will persist the feedback (async database call) and publish a FeedbackCreated event on the bus.
  2. The web server will send a SendFeedback command on the bus and the end point will have a message handler that persists the feedback and publishes a FeedbackCreated event which will be handled by the same endpoint (or should i send two local messages for the email???)
  3. The web server will send a SendFeedback command on the bus and the end point will have a saga that kicks in and takes over.

So I guess I'm confused on if after the feedback is persisted to the database should i publish an event or send two messages(which will be handled locally)? please not the message do not have all the info for the email so additional information will need to be looked up.

thanks!

Marco
  • 2,453
  • 3
  • 25
  • 35

1 Answers1

2

As you already stated, there is a couple of ways this flow can be implemented. I'll just tell you which one I would prefer, and then say a few words on why :)

First off, I would try to avoid accessing the database AND publishing to the bus from within a single web request. The less you can get away with doing in a web request, the better - and SENDing a single message with the bus is usually the most safe thing you can do, because it will not look up subscribers, it will not run into a deadlock in a database, and it will usually not be affected by anything else.

Therefore, I would await bus.Send(new CreateFeedback(...)) and then the web request would be over.

In the backend I would probably implement your 2nd option, i.e. have an IHandleMessages<CreateFeedback> that persists the feedback to the database, and once that has been done it could definitely await bus.Publish(new FeedbackCreated(...)).

You could then have the same endpoint (or another, doesn't really matter) subscribe to FeedbackCreated and then make a couple of handlers there do whichever SmtpClient things they need to do.

Please note that if you handle the event in the same endpoint, you can definitely have two separate handlers, BUT they will not be able to succeed/fail independently of each other. This might call for having two separate endpoints subscribe to the FeedbackCreated event.

I hope that makes sense :)

mookid8000
  • 18,258
  • 2
  • 39
  • 63
  • Perfect thx bud makes sense! Now let's say all I needed too do was write a single record to the database. For example an announcement. If the user is looking at a grid of records then creates a new one using the bus, most times the grid would not show the new record due to eventual consistency. How do u typically handle this? Would u just write to the dB during the Web request? Train your users to know they might have too refresh the page? – Marco May 07 '16 at 14:24
  • Yeah sure, you probably cannot get away with just sending a single message all the time. So for scenarios where the local data is expected to be updated, I would definitely go ahead and do that. – mookid8000 May 07 '16 at 14:51
  • Good answer @mookid8000. Marco, about the eventual consistency part, UI frameworks like Angular can really help here. Instead of doing a direct call into the db or "train visitors to do a refresh", a UI framework can build up state inside the browser. Store your new row there and upon refreshing the entire page, the row is probably already coming from the database. Same with cache. You're probably already using cache, how do you cope with stale data there? Data in db, but not yet in your cache? – Dennis van der Stelt May 09 '16 at 07:07