🎯 Key Takeaways for quick navigation: 00:55 🔄 Item potency means the same operation produces the same result, crucial for consistent API behavior. 03:15 📝 Pay attention to the "post" and "patch" HTTP methods, as they can create or modify data, demanding careful handling of item potency. 04:41 🔑 The solution to item potency issues involves using an item potency key (X-Item-Poy-ID) to ensure requests aren't processed multiple times. 05:08 💾 Store the item potency key in a memory system, such as a database or cache, to manage consistent API behavior. 06:58 ✅ Attach the item potency key to your requests, preventing the same request from being processed twice. Made with HARPA AI
@mujibulhaquetanim5 ай бұрын
thanks man
@soulGrafitti3 ай бұрын
Nice video. I really like your examples and approach. Around 03:33 you discuss why POST and PATCH require idempotentcy but the other HTTP methods don't. There is a lot of information arguing the opposite which I found when I googled POST and PUT. At a glance the reasoning one way or the other seems to depend on the exact use case and how effectively the return status codes are managed. Perhaps you could add some discussion or commentary addressing the divergence of opinion.
@cariyaputta Жыл бұрын
So it's equivalent to the concept of pure function?
@positivity1016 Жыл бұрын
Good point, sounds similar
@SoftwareDeveloperDiaries Жыл бұрын
It is 🙂
@henrybigelow35704 ай бұрын
No. A pure function is a function that has no side effects. An idempotent function is one that, if called once, has the same side effect as if it is called more than once.
@kazuar87 Жыл бұрын
6:37 what kind of cache? The automatic subtitle does not get it either... :)
@SoftwareDeveloperDiaries Жыл бұрын
Redis 😛
@milindsankeshware4233 ай бұрын
Do you have any video posted on Spring Rest API/ Microservices ? If yes then could you please share ?
@SoftwareDeveloperDiaries3 ай бұрын
Hey mate, unfortunately I don't do Spring specific videos but I talk about microservices in my System Design & Architecture playlist: kzbin.info/aero/PL5Lsd0YA4OMFvX88T5xH93NqBALI7TENz
@TannerBarcelos7 ай бұрын
The best video explanation of this very critical issue high scale, highly reliable systems face. Subscribed!
@josecarlostoscano5837 Жыл бұрын
Would repeated calls of the function ‘makeRequest’ have different values for the idempotency key? If they do, then the api would process both of them, wouldn’t it?
@juraev0056 Жыл бұрын
Yes, `makeRequest` makes a new request. You should make retry requests with previous failed request's idempotent key. You can see he's handling retries with `shouldRetry`
@SoftwareDeveloperDiaries Жыл бұрын
No, the idempotency key is the same for all retries for a particular user. The client can save the key in the SessionStorage while the user is still on the "Order" page and delete it after the order has been placed successfully.
@verb0ze11 ай бұрын
I don't know if I agree with not needing to concern ourselves with idempotency for other methods. I'd say it depends on the API. There are some cases where DELETE for example should be idempotent, like when deleting an item from a doing cart (and setting the total cost for the remainder of the cart
@MrMashyker6 ай бұрын
Exactly! HTTP methods are just conventions: devs are free to implement them however they like.
@actitud14 күн бұрын
Very well explained. Thanks.
@AhmedAli-jx9ie Жыл бұрын
how exactly the request will be retried with the same idempotency key?
@SoftwareDeveloperDiaries Жыл бұрын
The frontend can save the idempotency key in the SessionStorage as soon as the customer lands on the "Order" page and use it for every retry. Upon a success, the frontend clears the key.
@throwaway-lo4zwАй бұрын
@@SoftwareDeveloperDiaries this is a stupid solution i can just change that key and get multiple refunds
@naveenkumar-pg7te4 ай бұрын
Can this be achieved with transaction? If first request fails in service just revert everything dont create burger and send error message to client
@SoftwareDeveloperDiaries3 ай бұрын
Yes, that's a great point!
@idle.observer4 ай бұрын
Can someone explain, when we should remove the idempotency key? I think we shouldn't save all the keys forever.
@SoftwareDeveloperDiaries3 ай бұрын
Either after the processing has been fully completed, for ex. the order has been delivered to the client or you set a custom TTL.
@JohnSmithhh3 ай бұрын
Cool video ! How to make ajax request idempotent in a situation where user can create for example cards on the page ?
@abdrnasr Жыл бұрын
Great video! Don't you think that storing this temp value on the client is not the most secure way? A client could easily clear cookie. If there is a mechanism in the backend that deals with duplicate requests, then this is a different story.
@SoftwareDeveloperDiaries Жыл бұрын
Good question! The user should be somewhat aware that if they face an error upon let's say, clicking the "Pay" button and clear their cookies right after that, then that's not in their best interest and can lead to unexpected consequences such as paying twice. At least that's how I see it :)
@MaartenRaasveldt3 ай бұрын
Shouldn't you store the idempotency key in the database you're writing the order to so that it's transactional? Otherwise if the program crashes at any point between "executing" the order, and writing the idempotency key to storage (like redis), you'll still have the same problem
@SoftwareDeveloperDiaries3 ай бұрын
Thanks for your comment, that's actually a good point. Storing it together with the main data that's being written is prob the best idea most of the times.
@rahulbabbar5558 ай бұрын
Hey! nice explanation.. Which software you are using to demonstrate this..
@SoftwareDeveloperDiaries8 ай бұрын
Eraser.io :)
@yusufnurwahid8983 ай бұрын
Very clear explanation!!! Many thanks!!!
@cybersholt Жыл бұрын
Really interesting topic, been doing web development for 20 years and luckily never had anything like uber eats had! But the video was done really well and am looking forward to more from ya. Keep up the great work man
@SoftwareDeveloperDiaries Жыл бұрын
That's definitely for the best! :D Thanks mate!
@CodingWithAuryn11 ай бұрын
Very helpful!! Thank you for this nice explanation!
@anandraj28952 ай бұрын
pretty good , informative
@viraj_singh Жыл бұрын
When I was in my university, I ordered so many free food at the time of the glitch. Later on I was banned from uber eats and then uber and I just made a new uber account ande moved on. :) Great video by the way.
@SoftwareDeveloperDiaries Жыл бұрын
Hahah nice one!
@jonatasdeoliveiracoelho46915 ай бұрын
Extremely helpful! Thanks a lot! Subscribed!
@M0HCT3R Жыл бұрын
It would be interesting to see the solution for backend
@SoftwareDeveloperDiaries Жыл бұрын
Hope this is somewhat of a help :) medium.com/dsc-hit/creating-an-idempotent-api-using-node-js-bdfd7e52a947
@EmmanuelOdii80 Жыл бұрын
Hey, Great video. Meanwhile, I'd love to know if tou use Nest js :)
@SoftwareDeveloperDiaries Жыл бұрын
Thanks mate! No I haven’t used it yet, do you? 🙂
@EmmanuelOdii80 Жыл бұрын
@@SoftwareDeveloperDiaries It's been the go-to for my SaaS products :)
@rajaerobinson Жыл бұрын
Great video!
@mansoormasoudifard86246 ай бұрын
I learned a lot 👌
@developerfoe Жыл бұрын
amazing video
@SoftwareDeveloperDiaries Жыл бұрын
Thanks!
@throwaway-lo4zwАй бұрын
ok so basically u can just have like a status column in your refunds table or whaterver which is type bool which can be set to true if the backend has already processed the burger refund rather than this idempotency key bullshit lol