Debouncing

1. What exactly is Debouncing?

Your video player calls an ASP.NET Core API to save the playback position every time the subscriber drags the progress bar, not just once when they let go. Dragging across a long video moves that bar through a lot of points before the subscriber actually stops.

Each of those in-between points fires its own separate call, and each call writes a row to Azure SQL. A single drag from one end of the video to the other can send dozens of these calls in a few seconds, even though only the very last point, where the subscriber actually stopped, is the one that matters.

Every point the progress bar passes through on the way triggers its own write, when only the point it stops at actually matters. That's exactly what debouncing avoids.

2. How would you fix it in JavaScript?

Debouncing waits for the dragging to actually stop: add a short delay, for example 500 milliseconds, that starts over each time the progress bar moves again, and only send the save-position call once that delay passes with no further movement. If the progress bar moves again before the delay finishes, cancel it and start a new one from that later point instead.

Use: setTimeout, clearTimeout

Wait for a pause in the activity before acting, so one call carries the position that actually matters instead of many carrying the ones that don't.

3. How can you visualize it in everyday terms?

A grocery store's automatic door doesn't open on every step you take toward it. It waits until your approach has actually paused before it commits to opening, so it opens once for one approach, not once per step.

If it opened on every step instead, it would swing open and shut over and over as you got closer, doing far more work than a single opening ever needed.

Wait until the movement pauses before acting, instead of reacting to every step along the way.