WEBHOOKS With .NET Minimal APIs
Vložit
- čas přidán 28. 06. 2024
- Webhooks are an important pattern to communicate with providers/services that you don't control. The good news is that webhooks is one of the use cases where the .NET Minimal APIs really shine. In this video I'll walk you through what exactly webhooks are, how they work and how we can implement webhooks both from the point of view of the provider and the consumer. Everything with .NET Mnimal APIs.
#dotnet #aspnetcore #csharp
Join this channel to get source code access and other perks:
/ @codewrinkles
Also follow me here (especially if you are a self taught developer):
✅My other channel: / @danpatrascutech
✅Facebook: / danpatrascutech
✅Instagram: / danpatrascutech
✅TikTok: / danpatrascutech
✅Newsletter: www.danpatrascu.tech/
Content:
1. Intro: 00:00
2. Practical use case: 00:25
3. Polling: 01:02
4. Polling implementation: 01:40
5. Downsides of polling: 04:49
6. Webhooks to the rescue! 06:01
7. Supporting webhooks in our services: 06:52
8. Implementing webhooks: 11:07
9. Summary: 15:39 - Věda a technologie
Thanks a lot Mr.Dan for that awesome real world example.
need more of these real world examples. happy week off and welcome back
Glad you liked it!
Thankyou so much for such a wonderful real time explanation of how and why to use webhooks. This is the only video needed to understand webhooks!
Fantastic!
I guess the next evolution would be some sort of database or cache on the server side that would store the statuses in case the webhook call fails or is unavailable.
That's up to the provider/service to decide. As mentioned in the video, in these scenarios you usually don't control the provider.
great video. One question: similar result (avoiding polling the back-end) is not achievable with SignalR ? Could you make a video with the same project using SignalR Hub explaining main differences?
Thanks for the suggestion. Sounds really interesting. I also said it in my video, usually when you have to provide webhooks, you usually don't control the provider/service side. I've never seen one accepting websockets connections. But in theory, you could use SignalR, provided that it's supported by the provider.
But the suggestion to also create videos on SignalR is actually a good one. Thanks again.
Thank you so much for this wonderful video
Most welcome 😊
Great channel in general, the thing that would bring it to the next level is sharing your code from the videos.
I do this already. I share the code inall videos with members on ambassador level.
Great video, 👍🏼. What happens if you managed to miss a webhook message in your consumer?
That's a good question. However, what happens if you miss a regular call in your API? Core idea is, that doesn't happen very often. What you can do if it happens it depends also on what options that provider gives you. Usually these providers also offer REST APIS, so you could have a service that does a reconciliation by making an API call and comparing the response to the current data you hold in your application. Also some providers use retries if your endpoind can't be reached. Or they provide you with instructions on how you can get hold of the missed POST
@@Codewrinkles exactly my approach in my last project. I did a REST call after the fact.
I saw some providers making REST endpoints available that would list all failed attempts to post data to your webhook. But that sounds more like paradise and probably it's not something you'd find very often :)
@@Codewrinkles Indeed, i had a retry mechanism but outside of that i had to poll myself
Realtime systems (systems that use events/callbacks for data exchange) are nice but I feel like they need to be backed by a fallback mechanism (polling, retry etc) so that you don't end up in a situation where data is missing and you have no idea what happened. Web traffic is brittle and a small hick-up or downtime on your end could lead to missing the callback message.
I implementened a webhook-like feature in a backend system once, where the backend (the provider) persisted the "callback job" to a database, and retried the callback until a 200 OK was returned from the webhook. That way the backend could be sure that the message was atleast received by someone succesfully and it did not just disappear into nothingess.