Hacker News new | past | comments | ask | show | jobs | submit login

One of the highlights for Phoenix WebSockets came from the insights of one of my co-workers. I was having a problem where I only wanted to send websocket traffic up to 1 time every 3s (debounced essentially). I was struggling with this solution and came up with a hacky solution that would debounce on the event broadcast side (vs the socket side). This means it would be up to 1 time every N seconds per server.

Co-worker showed me that sockets are just processes, and that once the process exists, I can treat it like any other process. We wrote a fairly simple state machine for debouncing, and made it debounced on the socket side. It's awesome because it's debounced even in a distributed setup. Less than 25 lines of code for all of that!




For some channels / topics I let the clients provide a `refresh_interval` parameter upon joining to tackle similar problems. I'm also curious to see your state machine, maybe it's something worth extracting to a middleware.



I'd love to see how you accomplished this if you wouldn't mind sharing a gist or a post?


Here's a gist showing how it works (with anything secret removed): https://gist.github.com/sb8244/e6884ad08d91de8c4aa5bf3241855...

This would be an interesting blog post, as the format for the state machine and logic behind it are quite fun.


Thanks for the gist. Drop a link here if you end up doing a blog post too - wouldn't want to miss it


I'd love to see a blog post on this. Sounds like a good candidate for the Elixir Radar.


I think it would be cool to write a post about this. I'll talk to my co-worker about this as he did help out with a lot of it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: