I could make an AJAX request that displays the online users for each user. The request is done every 5-10 sec. or whatever. The problem is, isn't that overloading my server too much? Is there a way to do it that it will update the online users for everyone else instantly?
If you are looking for a system that can be used to indicate "Presence" events (Join/Leave/Is Typing/Geo/Lat/Long/etc) in real-time, you should check out PubNub:
http://www.pubnub.com/
Of specific interest to you would be the publish, subscribe, presence, and state APIs.
Both PHP and JS client SDKs are available:
https://github.com/pubnub/php
http://www.pubnub.com/docs/javascript/javascript-sdk.html
geremy
Related
I have an app where basically players challenge each other. At some point their challenge completes and I need to provide them (both of them - there are two players) with an update message, like 'Hey, you won and got 100500 points'. And vice versa - "Hey You looose"
I use websockets and pusher api to tackle the live updates, this works perfectly when player is "online". But what if they are not? The way to go for me looks like I can still handle the event with pusher and instead just displaying the message, I can store it to db to table challenge_notifications with fields messages and seen = 0. it's ok, but what would be the best way then to show this to the player when he comes online next time? I don't want to have ajax request on every page load checking to see if there are any unseen notifications for the user.
I probably somehow need to fetch all pending notifications only once, when they get online?
I use Laravel 5 for my backend.
There was a recent post on the Pusher blog about how to detect if a user is online or not using the Pusher HTTP API: Enabling Smart Notifications with Pusher and SendGrid.
The example uses SendGrid, but you could instead store the update to a database, send them a Push Notification, an SMS etc.
what would be the best way then to show this to the player when he comes online next time?
I guess there are two forms of "coming online":
The user is no longer on the site and has to navigate to the site. In that case as the page loads you can query the DB and serve them up any missed notifications directly (this would seem the easiest solution). Or, if it fits your app architecture, make a single AJAX request when the page loads to get any missed notifications.
If the user has gone offline due to them being mobile or having a bad network connection. In that case you can bind to the connected event using pusher.connection.bind('connected', function() {}); and then make a query to see if they've missed any notifications.
In summary: it would seem that querying the DB for any missed notifications upon normal page render (on the server) would be the simplest solution and wouldn't required much resource usage. But there are alternative mechanisms of delivering a notifications (email, SMS) if they're not online.
I have a website running on shared server with apache/mysql/php. Each of the pages of the site belongs to one registered user and this user,once logged in can edit the page. Other users that are not owners of the page can only look at these pages but cannot do anything else.
Now I'm planning to add chat functionality to my application. The basic idea is that if owner of the page opens it in a browser, and is logged in, he will be shown for other users (that will be anonymous) as "available for chat". Other users visiting the page will be able to send him messages and vice versa. Anonymous users do not need to communicate with each other and they can communicate only with registered user (owner of the page). So basic structure would be like that:
anonymous user(s) visits the page. Registered owner of the page is not looking at the same page and chat is not available.
Registered owner logs in and opens his page in a browser. All registered users in real time are informed owner is available for chat now.
Anonymous users can send him messages.
Registered user receives the messages and can respond back to each user
Other users can join and chat with registered user any time. It all happens in real time and registered user can see who comes in to visit his page and goes away.
Now, in step 3 and 4 I need to know if the registered user is still logged in. If so then the messages can be passed further to intended user. If not then instead I need to send a message that the owner (registered user) is no longer available for chat.
I'm looking for advice on how to best implement it:
using old school php and ajax calls. So every user would send ajax request every second or so to server and server would keep track of each conversation somehow. Relatively easy to implement I think. I'm not expecting large number of users but I can imagine this would be heavy on the server.
using node.js.
Now my questions:
What could be possible problem with solution 1 above. Would that be too heavy on a server constantly throwing ajax requests at it? would would be reasonable number of users I could accept?
Using node js on my shared hosting.. assuming its possible to install it and run it on separate port, how would I best go about checking if registered user is still logged in or not? Any ideas would be much appreciated as am out of ideas here.
You're right that the PHP/Ajax calls can cause quite a bit of server load, especially if your Apache/PHP stack needs a lot of memory to bootstrap. Many chat modules in PHP systems, e.g. Drupal, actually offload this responsibility onto a specialized node.js server (the second approach you mentioned) to facilitate scaling.
Another approach you may consider is to use a real-time network such as PubNub to facilitate this user-to-user data transfer. PubNub has a toolkit called Presence which can help with telling who is subscribed or unsubscribed to each channel.
To fit this to your requirements, I imagine that each user will register with the page they are viewing upon landing on it, by issuing this call in your JavaScript:
<script src="https://cdn.pubnub.com/pubnub.min.js"></script>
<script>
var pubnub = PUBNUB({
uuid : '12345-page35' //You can define this for each user
})
pubnub.subscribe({
channel : 'site-wide-chat,page35', //Subscribe to two channels!
message : receive_chat, //Callback function
presence : user_joined //Callback function
})
</script>
When the "owner" logs in the other users viewing the page are notified. You can accomplish that like this:
function user_joined(event) {
if (event.uuid.match(/page35/)) { //You can set your own test here
// .... admin available for chat
}
}
Presence also has a bunch of nifty features such as the ability to get all users subscribed to the current channel:
pubnub.here_now({
channel : 'page35',
callback : function(m){console.log(m)}
});
I hope this helps you build your minimum viable product. Since everything is implemented at the programming language level, you should have a lot of flexibility crafting a customizable chat solution without adding additional complexity or overhead on your server.
We have developed a product that is used for employee engagement. It provides a feature that shows tweets posted by members of your office if they have authorised the site.
The fetching of tweets is done by a periodic cron that is run at a regular interval at about 15 minutes. This cron searches for all the users who have authorised the site's app
and makes requests twitter for their tweets. For every user one request is send to twitter
Currently the system is using REST API (http://api.twitter.com/1/statuses/user_timeline.xml?user_id='xxxxxx') that is limiting number of request to 150 per hour.
We cannot make authenticated requests as it requires the user to authorise the call every time, which is not possible while making the requests by cron. So, with just 150 requests
and cron running four times an hour it is possible to fetch only 35-40 users data which cannot meet our requirements.
Also we have explored the option of Site Streaming API. But it requires a persistent connection to be established with twitter which would be difficult while using the cron. Another concerns with Site Streaming API is that it is in beta version and the website should be whitelisted.
Kindly assist us in selecting the best possible alternative that would help us meet the above mentioned objective
There are two solutions.
Create an account to follow the users who have authorised your app. Then, simply retrieve that timeline.
or
Place the users in a "List". Then make a call to lists/statuses
I am not 100% certain why you cannot stay logged in via Cron hwoever, as you are using PHP, can I suggest that you look at https://github.com/jmathai/twitter-async/blob/master/EpiTwitter.php which authenticates your oAuth and then does what you want and closes the request.
If you cant do this with Cron, use serviceUptime.com to call a php script although the max time the script can run is 35seconds so don't try and pull all the lance Armstrong tweets back all at once. HTH.
I am building a website app using Facebook PHP API. My current scenario is I want my server side to get updates from Facebook when a user of mine app(he already give the access_token) has some updates. e.g.: if the user post a comment, if someone post a comment on his wall, send him a message, I wish in my server side I can get this notification.
I have checked out the graph API's realtime updates, but I didn't get if I can use the realtime updates to do the above tasks. I wonder if someone know if the realtime updates can do this or not.
The second solution would be: since I have the access_token, I can periodically check the information of the user to see if there is any new updates. The disadvantage of this approach is that it puts lot of heavy on my server side.
The real-time updates API documentation says:
"You can't subscribe to these user connections yet: home, tagged, posts, photos, albums, videos, groups, notes, events, inbox, outbox, updates, accounts. We will add support for more properties and connections in the future."
The three examples you listed are all not available at the moment. For now, you will need to poll the Graph API every so often to check. You will want to prompt the user for offline_access extended permission to be able to check this later after they leave your site.
I am trying to implement a Facebook-like live notifications system to notify users whenever someone adds them as friend, like their post or posts replies to their comments.
All the database and PHP part is done, but I can't figure out how to implement it like Facebook has.
Whenever someone likes/comments on your post in Facebook the light blue box appears at the bottom left corner of the screen. This happens as soon as someone hits like button or posts comment in Facebook. I would like to know what I should do to implement this.
Using YUI or any JavaScript framework I can query a database table after n seconds to check for notifications. This method is too heavy.
I was wondering if there is any server side mod or scripting can be done so that whenever there is new notification entry in my database table the server will tell that particular client. That way unnecessary request calls from client to server will be avoided completely and system can work efficiently for website with more than 50,000 users online at a time.
How can I achieve this?
You should look into COMET techniques, such as forever frame (tutorial) and long polling. That allows you to have a form of a server->client push communication.
I am really surprised nobody has mentioned PubNub and Pusher
These two (competitors) are building infrastructure which allows for realtime notifications, just like Facebook.
Facebook notification
You basically set a request up, like callng the service that asks your server/db for the notifications of that user. You may do a while loop that retries if theres no notification (maybe Thread.Sleep in between searches). Your js request will timeout, then you can call the function again in timeout. This means long polling afaik
The only way to do it is to have some sort of mechanism (e.g. Javascript) to repeatedly poll the server for updates. Doing server pushes to web browsers isn't possible.