Design Nugget - Adapter Design Pattern - Testing Service Bus using RabbitMQ Locally

[@valtrav8996]

message bus scenario as an example to describe the adapter pattern is perfect. best video I've seen on the subject. ty

[@Matlus]

Thank you Jim!

[@karthikrengasamy814]

Shiv, this is an awesome video.

[@vinays4757]

Nice video. It was interesting , backed by good analogies for adapters from hardware perspective. Please continue uploading good videos like these. Would also be interested to watch your work on PCBs .

[@Matlus]

Thank you Vinay! I do want to make IoT videos, hopefully sooner rather than later.

[@TheChandan0285]

Thanks Shiv for sharing knowledge with excellent video

[@Matlus]

You're welcome Kumar

[@ahmedilyas8365]

As always it seems, interestingly, this is the EXACT same thought process I have and understanding too and what I implement and echo to developers. This is yet another excellent video! So glad you I was able to validate my sanity on these things!

[@Matlus]

"same thought process" - That's good to know Ahmed. Now let's hope we're both correct :). Thank you for you comment as well Ahmed, much appreciated.

[@sumitmore4680]

Shiv, excellent video like always. I really appreciate the minute detailing in code as well as in presentation 🙌🏻.

[@Matlus]

Thank you Sumit! Tank you also for calling out the code details!

[@AAronnAAs]

I've got an Alexa dot by my computer speaker. She replied "Ok" after you asked her to turn off and on the "video lights". Then I tried it, and she said "Ok". I'm shocked. What is she turning on and off here at home? I don't have anything named that!

[@Matlus]

LOFL!! You've got something there that's turning on and off! You're going to have to figure it out. She's never wrong!

[@saurabhchauhan232]

I really enjoyed this, actually this is very nicely presented with real-worldexamples and code example and some funny alexa conversation. Thr plus point is you said in your mind patterns are very clear and it took years to get that thought process. I am thankful that sitting at home I can learn / adapt things from your experience. Have no teacher professor or mentor in my career but I respect you a lot thanks for all the hardwork. If you can continue or bring some more design patterns it would be really helpful I have seen most of from your channel and I am clear but I have a doubt here can you please help me to clear that, here I could see template method and something simillar to gateway. So while we are talking with 3rd party api we should call it Gateway (obviously it has many more things to do) but when talking with 3rd party assembly or dll like this we should call it adapter??? is it just context difference or I am still missing something or understanding it wrong ?

[@Matlus]

Saurabh, thank you for voicing your appreciation! I appreciate you taking the the time to watch and learn from my videos but more importantly commenting and letting me know in a well thought out comment. Your question is a good one indeed. You could look at the code I've presented as a Gateway too. You use an adapter when both sides (of the API) are fixed. And you need something in the middle to help you "adapt" such that the two sides can fit and work together. So if you can image that the system's API is fixed and the SDK (RabbitMQ/ServiceBus) APIs are fixed, but you'd like to use either or both in your system, then how would you bridge those gaps? You'll need an adapter to adapt from RabbitMQ to your system's API and an adapter to adapt from ServiceBus to your system's API. Hopefully that makes sense?

[@saurabhchauhan232]

@@Matlus Yes 100% clear from this perspective but isn't the gateway do same thing? What I understand from gateway it helps you to talk in your domain language (where there's fixed way to talk outside to domain) while this helps the other above mentioned way am I correct?

[@Matlus]

@@saurabhchauhan232 They're doing similar things, yes. But the adapter design pattern is not limited to my example. You should/can use it any time you're dealing to two fixed yet disparate APIs and you need to adapt the APIs. Let's say you're dealing with a graphing/charting third party library. You application needs then to supports a specific/particular API. Their API is different. So you adapt. I guess it's unfortunate that I used message brokers as an example here :). Also, Gateways are from services (REST, SOAP, Grpc etc.). You may need to adapt there as well, but they're gateways. Decoupling and abstraction are key concepts of OOD. So you'll see these thing happening in all well designed classes.

[@saurabhchauhan232]

@@Matlus understood "those are Gateway but I may need to adapt there as well". Thank you for explaining in detail

[@Matlus]

@@saurabhchauhan232 You may need to adapt something that not anything like a gateway :)

[@hansrudolf5849]

Hi Shiv, just out of curiousity - what is the reasoning behind the CloseAsync()? Doesn't this add additional overhead while not giving any benefit? (due to the fact that the thread is still blocked due to the continuation task with Task.Wait())?

[@Matlus]

Hi Hans, is there a time code you can point me to so I know the context of your question?

[@Matlus]

Ok, I see it. You're talking about the code in the Dispose method correct? If so then here is what's happening: We need to Close. However the method is async. (CloseAsync) but we can't call await in the Dispose method since it is not a Task returning method. So I'm using the old style (before async-await) of call a continuation (A call back). The ContinueWith method will be call when the task is complete. But since the task is complete, the Wait() will return immediately (it's not going to block). One could argue (as I think you are) that we don't need the wait then. "Need", no, that's correct. However having an empty implementation (the ContinueWith method) could indicate to static code analysis and human programmers that it's not needed. But in fact it is needed because we do want to "wait" till the task is complete before we finish the dispose method. Make sense?

[@hansrudolf5849]

@@Matlus Thank you very much your extensive reply Shiv! Didn't think about the static code analysis tools - great point. I was just curious if there is also a Close instead of CloseAsync() method and wether it makes the difference to call Wait on CloseAsync directly .. :) I assume ContinueWith resumes the execution on the same thread context as its predecessor task? Anyways once again I got to witness some well though out code! Keep up the amazing work!

[@Matlus]

@@hansrudolf5849 call wait directly after CloseAsync() will be a blocking call. Calling ContineWith makes it a non blocking call. Does that answer you question? Another way to look at it is, that if you have an async method but you can't use await (like in this case) then you should use ContinueWith which is non blocking and the ContineWith is called only after the task completes.

[@hansrudolf5849]

@@Matlus you are absolutely right Shiv - of course this makes a difference.

[@colebq]

Thanks for the video. Is there any way we can guarantee message ordering with RabbitMQ, in case of multiple consumers of the same queue? Service Bus allows that by using the Session. Scenario: - Publishing events: SalaryUpatedEvent(200); SalaryUpdatedEvent(2000); - Due to processing problems or latency we end up processing: SalaryUpdatedEvent(2000); SalaryUpdatedEvent(200); which would be a big problem :)

[@Matlus]

If you need message ordering, you can't have competing subscribers typically. One subscriber could finish sooner than another one. Of course you only need competing subscribers if you what each subscriber does with the message is long running. The message brokers themselves can guarantee order so as a consumer you'll need to figure out what or how to ensure order.

[@vinays4757]

First view & Comment 😎

[@Matlus]

That was quick!