Publisher Subscriber Pattern - Build your own .NET Message Broker
Вставка
- Опубліковано 5 жов 2024
- In this video we take a look at the Publisher / Subscriber pattern (otherwise know as Pub/Sub) that's used to facilitate distributed systems interactions in a decoupled way. To fully explore this topic, we build a Message Broker app step by step, then introduce an additional lightweight subscriber app.
🌐 Links 🌐
💾 GitHub Repo: github.com/bin...
🎓 My other courses: lesjackson.net
📕 My Book: link.springer.....
🤩 Patreon: / binarythistle
🌲 Linktree: linktr.ee/bina...
🔗 Publisher Subscriber Pattern: learn.microsof...
🔗 Installing EF Core Tools: learn.microsof...
🔗 DBeaver: dbeaver.io/dow...
⏲️ Time Codes ⏲️
Introduction & Theory
----------------------------------
0:42 - Welcome
1:15 - Demo
5:05 - Call to action
5:42 - Theory
9:23 - Solution Architecture
12:01 - Scaffold the Broker
16:11 - Data Model
19:17 - Message State
Message Broker Coding
---------------------------------------
20:30 - Models
25:52 - DB Context
30:51 - Migrations
33:48 - DBeaver
35:38 - Endpoints overview
37:12 - Create Topic Endpoint
41:12 - Get Topics Endpoint
42:54 - Create & Get Topics with Insomnia
46:10 - Publish Message Endpoint
55:14 - Test Publish #1
57:37 - Create Subscription
1:02:02 - Test Subscription Create
1:03:49 - Re test publish message
1:05:02 - Get messages for subscription
1:11:06 - Test get messages endpoint
1:15:53 - Acknowledgement endpoint
1:21:14 - Text ack endpoint
Subscriber Coding
------------------------------
1:23:28 - Scaffold Subscriber
1:25:04 - Message Read DTO
1:27:12 - Read Messages function
1:34:37 - Acknowledge messages function
1:37:36 - Polling routine
1:40:51 - End to End testing
1:44:44 - Patreon Credits
Would love a follow up production version using Azure service bus.
This is a nice content, could you also create clean architecture setup with real project scecnario, like creating repository pattern, cqrs, mediatR, integrating with database using clean architecture? thanks in advance :)
Great content, now I have something to look forward to do after work today ;). Thank you for these amazing videos.
learning a lot from your video tutorial, appreciate it a lot, big up Les
Happy 100k followers 🎉😊
I am very grateful for your generous work 🙂
Your content is always solid 🔥 Please make a video about SAGA pattern.
Wonderful.. 100k coming soon. 👍
Very good content. One thing that i need to add while you are adding record then can you simultaneously show the db record? It ll be easier to understand.
Good video, very clear explained.
A good video. BUT the video goes on for almost two hours, and all we see in the end is a while loop with a request to receive messages. There is no real subscription, for example, a callback. There is nothing about load regulation and message queue overflow.
Thank you for this amazing video
Thanks for this. Highly appreciated. I have a few questions:
1. Will persistent Tcp connection btw client and broker scale better than polling? (I'm seriously having doubts as to which one would scale better as on the one hand, too many concurrent connections can exhaust port availability or even overload the broker whereas on the other hand, too many clients can quickly flood the broker with constant polling requests)
2. Does Kafka or any other message broker allow / prefer 1 method to the other?
2. In general, Which method is preferred / currently being used by companies that manage a lot of messages.
Thank you!
Loved it, thanks
Thank you máster.
thank you so much for the useful videos
El mejor canal de Dotnet! me suscribo
Hello les please tech us about how to use signalR in web api
Time 1:21:00 I suppose the FirstOrDefault should be FirstOrDefaultAsync?
Awesome 👍😎👍 that'why I like it...
handsome charismatic individual? 😃
Having established that publisher should be unbothered by none/number of subscribers, seems contrary that messagebus should respond with any unhappy error code (having dropped unwanted msg iff no subscribers), although I agree that publisher can ignore such warning and plough on regardless.
The eventual C# consumer then used the hardwired Id (created manually earlier) rather than request (and teardown on exit) its own SubscriberId, but ideal homework for viewers anyway!
Unclear why model's string properties are marked [Required] but with string? i.e. nullable which is contrary. Fortunately EFCore copes well and creates NOT NULL columns.
Curious mix of Any() vs Count==0 but otherwise great!