message bus scenario as an example to describe the adapter pattern is perfect. best video I've seen on the subject. ty
@Matlus4 жыл бұрын
Thank you Jim!
@karthikrengasamy8143 жыл бұрын
Shiv, this is an awesome video.
@vinays47574 жыл бұрын
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 .
@Matlus4 жыл бұрын
Thank you Vinay! I do want to make IoT videos, hopefully sooner rather than later.
@TheChandan02854 жыл бұрын
Thanks Shiv for sharing knowledge with excellent video
@Matlus4 жыл бұрын
You're welcome Kumar
@ahmedilyas83654 жыл бұрын
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!
@Matlus4 жыл бұрын
"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.
@sumitmore46804 жыл бұрын
Shiv, excellent video like always. I really appreciate the minute detailing in code as well as in presentation 🙌🏻.
@Matlus4 жыл бұрын
Thank you Sumit! Tank you also for calling out the code details!
@AAronnAAs2 жыл бұрын
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!
@Matlus2 жыл бұрын
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!
@saurabhchauhan2323 жыл бұрын
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 ?
@Matlus3 жыл бұрын
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?
@saurabhchauhan2323 жыл бұрын
@@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?
@Matlus3 жыл бұрын
@@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.
@saurabhchauhan2323 жыл бұрын
@@Matlus understood "those are Gateway but I may need to adapt there as well". Thank you for explaining in detail
@Matlus3 жыл бұрын
@@saurabhchauhan232 You may need to adapt something that not anything like a gateway :)
@hansrudolf58494 жыл бұрын
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())?
@Matlus4 жыл бұрын
Hi Hans, is there a time code you can point me to so I know the context of your question?
@Matlus4 жыл бұрын
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?
@hansrudolf58494 жыл бұрын
@@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!
@Matlus4 жыл бұрын
@@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.
@hansrudolf58494 жыл бұрын
@@Matlus you are absolutely right Shiv - of course this makes a difference.
@colebq4 жыл бұрын
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 :)
@Matlus4 жыл бұрын
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.