slowlydev / f1-dash

A real-time F1 dashboard
https://f1-dash.com
GNU General Public License v3.0
411 stars 39 forks source link

feat(f1-service): use throttled debounce on emit #72

Closed simylein closed 3 months ago

simylein commented 3 months ago

This throttles the amount of calls emit can receive in a given amount of time. It also acts as a debounce. Let me know if 200 ms is okey, or if you would choose a larger / smaller time.

vercel[bot] commented 3 months ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
f1-dash ✅ Ready (Inspect) Visit Preview Mar 5, 2024 6:59pm
slowlydev commented 3 months ago

Thanks for the PR, I just thought about what happens when we do not deliver some update immediately and CarData as well as Positions came to mind, which heavily rely on new data coming fast. When using data-simulator I use delays between every message from about 10 to 100ms (in real live Positions gets updated more frequently than anything else) and the experience of the Map is quite bad.

So not sure if this is 100% a good idea, maybe we can find a middle ground between "combining" updates and sending some "instantly"

simylein commented 3 months ago

Well, either we work out the compression thingy or you put some smoothing on the map, because like this we will run out of bandwidth quickly without partial updates.

slowlydev commented 3 months ago

Okay then I will implement inflate in the frontend on your other PR ok?

simylein commented 3 months ago

Yes, but can we leave this open as an option? Because even with deflation it could get hairy above 2k users without partial updates.

simylein commented 3 months ago

Can we try 50ms as a compromise? That's still too many per second, but far better than something like 5ms which is currently possible.