Best way to use the Twitter API 1.1 with unauthenticated users - php

I apologize in advance for my English.
I need to get the last tweets about a specific subject (for example.. well.. Twitter!).
Today, i use https://search.twitter.com/search.json?q=twitter to obtain that.
But as you know this is deprecated and it will shutdown. So i try to use the 1.1 API with PHP (twitteroauth) but i have this issue:
Every visitors of my website get the last twitter statuses about a subject with AJAX. If the visitor stay in my page, the twitter data will be refreshing all 10 seconds.
EDIT : Please note that i have a big amount of pages and the subject is different in every of them.
Today, the majority of my visitors are not authenticated by my website, and by twitter.
If i use the PHP-way to get data and display to my visitors, i will be rate limited if the amount of my visitors are too high. There is my questions:
There is a way to build some "anonymous" token with my secret keys to "delegate" the rate limit window to my "anonymous" user?
If not, my use of the API 1.1 are realistic? How?
And, if not again, what is your recommandation, your advice to solve this?
Thank you very much for the enlightenment!

I decided to use the streaming APIs with PHP CURL with AJAX to get my data.

Related

Checking for new posts on Facebook

Is it possible to check for new posts on Facebook page (Fan Page or Personal Page)? I need to recognize new posts on page every X minutes. What are my options? Are there ways to do it without Facebook Api? And is it possible to do this with Api?
Thank you
This is possible with the Realtime API: https://developers.facebook.com/docs/graph-api/real-time-updates/v2.1
You can connect it to a Page or a User Profile. It´s much better than checking on your own with a Cron Job (for example), because Facebook will hit your callback URL on every change so you will never hit a rate limit. I´ve experienced that it is quite fast, new entries are recognized at least 30 seconds after they where changed/created, sometimes even faster.
Btw, it is not allowed without the API, that would be scraping and Facebook does not allow scraping: https://www.facebook.com/apps/site_scraping_tos_terms.php

Twitter API Rate Limit for Multiple Users

I am writing a PHP-based application using the Twitter API. Up until now I've been using the REST API via a GET request on a PHP page. However, as my app scales, I can easily see it going over the 150 requests-per-hour limit. Here's why:
I have categories of topics, each which periodically poll the Twitter API for tweets around a topic. For example, I have: mysite.com/cars, mysite.com/trucks, etc. A user can go to either page. When he is on the page, live, refreshing updates are pulled from Twitter by making an AJAX call to a PHP page I've set up. The PHP page determines which category the user is coming from (cars, trucks), polls Twitter for search results, then returns the JSON to the category page. This sounds confusing, but there are a number of unrelated reasons I need to have the intermediate PHP page.
The problem is that since the PHP page is making the requests, it will eat up the rate limit very quickly (imagine if there were 20 categories instead of just cars and trucks). I can't make a single call with multiple parameters because it would combine multiple categories of tweets and I'd have no way to separate them. I can cache results, but if I did, the more categories I add, the longer each would have to go between API calls.
So how can I approach this problem? I looked at the streaming API, but it's only for oAuth'd users and I don't want my users to have to log in to anything. Can I use the stream on the PHP page and then just make continuous requests each time the category page polls the PHP page? Thanks for any help!
a) You don't have to use your websites user's oAuth credentials in streaming API - just your's:
get them somewhere in dev.twitter.com and hardcode them. Your users won't know there is any oAuth going on backstage.
b) Don't use anonymous requests (150 per IP per hour) use oAuth requests (350 per oAuth per hour). You don't have to ask your users to sing in - just sign in few (1 is sufficient for start) your private twitter accounts. If you don't like creating twitter login functionality, you can get credentials for your twitter account to your twitter application in dev.twitter.com .
c) As #Cheeso mentioned - cache! Don't let every pageload make twitter request.

How to index tweet as soon as it is posted?

Is there a way to know that a user posted a tweet as soon as he does it? Maybe Twitter can ping your app or something?
What if I have a user base of 100.000 users? It's hard to check constantly all.
Thank you,
Andrew
Check out the Streaming API, specificially user streams: https://dev.twitter.com/docs/streaming-api/user-streams
You would use the Streaming API for this case. This is exactly what this does, you open a firehose and Twitter pings your application with new tweets every time there is an update based on your query. If your using PHP, you can make implementing the streaming API easier by using the 140 framework.
from streaming API method doc
The default access level allows up to 400 track keywords, 5,000 follow
userids and 25 0.1-360 degree location boxes. If you need elevated
access to the Streaming API, you should explore our partner providers
of Twitter data here.

Multiple twitter users' feed on one site without reaching the rate limit

I have a large number of twitter users I wish to sydicate onto a website using PHP and caching the tweets in MySQL. However I seem to be stumped by the rate-limit problem when ever I access the API. Every request I make to every user seems to count as a request, which stands to reason.
I notice other sites* doing this exact thing successfully. How are they getting around this, are they simply whitelisted, or is there a technique I'm missing?
*http://www.twackle.com/NFL/Aaron-Rodgers_1/tweets
The streaming API is what you are looking for, and more specifically, the filter method. Filter, at its least-privileged level, will allow you to follow 5,000 users in realtime, without them having to authorize your app, and you can track up to 400 keywords using this method as well.
Now, if you want historical tweets as well, you will have to pull those from the REST API (the streaming API's count parameter doesn't really help here), but since you can only retrieve the last 3200 tweets for a user via the REST API, you can pretty much backfill all available tweet history with 16 calls to statuses/user_timeline by passing in a count parameter value of 200 and paging accordingly.
http://api.twitter.com/1/statuses/user_timeline.json?screen_name=barackobama&count=200&page=2
http://api.twitter.com/1/statuses/user_timeline.json?screen_name=barackobama&count=200&page=3
http://api.twitter.com/1/statuses/user_timeline.json?screen_name=barackobama&count=200&page=4
With your 350 calls per hour per single Twitter account, you could backfill approximately 22 full user timelines per hour.
On the implementation side, you'd probably be interested in Phirehose, a streaming API client interface for PHP.
try to auth first, before get the tweets. that should increase the rate limit
A simple method of combining multiple user_timelines is to create a Twitter list and use GET /:user/lists/:id/status. That single API request will return the most recent tweets from all users on the list.

Facebook API Responses Very Slow (oAuth)

I am doing some benchmark testing on my web app and notice that the responses from Facebooks API are a lot slower than Twitters.
** For the record, I am using the twitter-async library for Twitter API integration and Facebooks own library here
With the Twitter library I can save an oAuth token & secret, I then use these to create an instance and make calls, simple. For Facebook, unless I ask for offline_permission, I must store an oAuth code and recreate an oAuth access token each time the user logs into my app.
Given the above I can:
Retrieve a Twitter users timeline in 0.02 seconds.
Get a FB oAuth Access Code in 1.16 seconds, then I can get the users details in 2.31 seconds, totalling 3.47 seconds to get the users details.
These statistics are from using functions Facebook has provided in their PHP API library. I also tried implementing my own CURL functions to get this information via a request and the results are not much better.
Is this the same kind of response times others are getting using the Facebook API?
Besides requesting offline permission and storing the permanent access token, how else can I speed up these requests, is the problem on my end or Facebooks?
Thanks,
Chris
I also have the experience the Facebook API is quite slow. I believe the facebook PHP API does not much more than wrap around CURL in the case of API calls so it makes sense that this didn't improve the speeds.
I work on a canvas page, which means for existing users, I get an access token and fb_UID as he/she comes in. At first, I did a /me graph call and sometimes a /me/friends. The first takes like 0.6 secs, the second usually a bit more. So in that case I can (to some extend) confirm your findings.
That's why I've now switched to storing important stuff locally and updating it only when needed (real time update API). Basically, I don't need any API calls during 'normal' operation.
I realize you are probably integrating FB on your own page, and perhaps use a bit more info than just name, fb-UID & friends, and that this solution is not totally answering your question. But perhaps it can still function as a small piece of the puzzle ;)
I am looking forward to other perspectives on this as well!
My application calls multiple URL's from Facebook. It does take some time :/
This is why I decided to write a function which stores the results in $_SESSION so I can use it again later, along with a timestamp to see if the data is too old.
This doesn't solve the actual problem, it just saves you having to keep fetching it.
What I like to do for end user experience, is forward them to page with a loading .gif - then have javascript request the page that actually fetches data. That way, the user remains on a loading page with a nice gif to stare at, until the next page is ready.

Categories