I manage the frequency of socket emits using RxJS, to prevent sending too many changes to users.
https://movinggauteng.co.za, there's a counter at the top of the page.
EDIT: Only saw a comment about why the OP used Ajax after posting this.
The reasons why I used WebSockets are that I get a disconnect event immediately, and I was already using WebSockets for other features on the site
But yes, if you're already using websockets for other features, there's no reason not to continue to use them, as you explained :)
I'm one of the creators of Real Time Users.
Only 1 AJAX call get sent to 'track' you on the site for each page load. The AJAX calls you're seeing are asking the server for the latest number of users on the site so that we can update the value displayed.
This isnt the most efficient way of doing this, as if the site has a low number of users, the count will return the same number most of the time. A better way would be to use websockets, however i only have limited knowledge of using websockets so we decided it was best to just stick to the tech we knew (Especially as we built it in a weekend).
If people start using this more, we might update it to use websockets though.
Hope that answers your questions. Let me know if theres anything else you'd like to know.
My implementation is in-memory, and the nice thing about it is that if fit example my Node.js app restarts, all active users will get disconnected, and they will emit a connection event, allowing me to get the count of online users again.
I can extract relevant code and share it if it'd help.
I've come across Socket.io before, and played around with pusher as well. And if i remember correctly, Laravel has built in helpers for sending websocket messages.
My main issue is actually running the node.js application, as its something i've not done before. That was another reason for not using websockets. Wanted to remove as many barriers that might slow us down or stop us from launching, so we stuck with what we knew.
I'm sure i'll update this at some point to use websockets though, gotta learn how to deploy node.js sites at some point :D
I'd say ajax is probably the right way as far as polling for the data goes. Using web sockets for polling incredibly simple data doesn't seem necessary.
Having said all that, with the number of requests that we're getting at the moment, i dont think it makes much of a difference. Though im guessing if we got a lot more traffic, then websockets would probably reduce our server load.
Who knows whether anyone will actually use it.
There's also a leaderboard, to track who does.
Just like the million dollar homepage guy - why didn't I think of that!?
Last week Marc Kohlbrugge launched https://highscore.money/. Following that, he sent out a tweet, asking if anyone knew of a good real time user counter to add to his site.
No-one did, so we made one.
Real Time Users is just that. We made it this weekend. I wrote a quick post introducing it, so feel free to look at that for more details.
Feel free to ask any questions, I'll be about all day.
You could read this ( I just duckduckgoed this, but it looked like what I remember it involves to do this).
Let me know if theres anything else you'd like to know
https://www.google.com/search?q=user+counter brings many websites offering this in various fonts, sizes and colors.
But then again, 'good' can be very subjective...
Please don't be dismissive of new work on HN, especially in Show HNs: https://news.ycombinator.com/showhn.html.
People are allowed to make things even when other things like that already exist, and they're welcome to share them here. The spirit of Show HN is "hey, I made this," not, "I declare a claim to priority".
A better way to post a comment like this would be to mention specific other projects in the space and ask how this one differs.
For us, this was just a fun hackathon over the weekend. But who knows where it will go, maybe we'll continue developing it out and it'll become something more. We'll see.
You are right though! :)
Sure, it can be nice to solicit explanations of differentiation from the OP to help understand the use cases, but these kind of sweeping comments aren't helpful to anyone.
For a long time we never shipped anything due to the need to try and make the next Facebook in one go. It crippled our creativity.
These days we've learnt that it's ok to build and launch something that's been done before, the most important thing is learning to launch. For us we launched this to get back into the swing of launching stuff after a few months since our last launch. This is entirely an MVP, built and launched in under 15 hours total design/dev time.
Thanks for taking the time to comment Colin.
I think its always good to do some fact checking...