Does Facebook provide access to any real time APIs so that you can respond to events as soon as they happen? If not, what alternatives are there and what are their limitations? For example, if I use polling instead, will they limit my api calls? And if I try using RSS feeds, about how much delay can I expect? Or maybe it would be possible to receive and process email notifications (if I could convince a user to forward mail to another email address), as they seem to be dispatched pretty promptly.
I've never tried polling user data, but I think it will work without issues. As far as I know there are no restrictions on the number of API calls you can make on facebook.
As far as the Queries are concerned, what I have seen and I think this is how they implement it. If your query asks for too much data(takes too much time to process is how they measure this I think) - the query will just fail.
eg: I had this app that would pull all the status messages of all the friends of the user and display it in one place. I first queried for all the friends of the user - this worked okay. But at the same time if I ran a loop to get all the status messages for each friend - it would just fail.
I think you can call individual queries without issues, just be careful you query only data you need, cause, if the queries are too big or too many they will just fail. Best way to findout is running tests yourself.
The Facebook Graph API will allow you to subscribe to real time changes. You can currently only subscribe to users, permissions and errors, but they promise to allow subscribing to more objects in the future.
Related
I am creating an application which has a follow mechanism where the followed user has to accept the request of a following (similar to private accounts on instagram).
I then want the following user to find out when the other user has checked a million times (every time the following user opens the screen if I did the query in viewDidLoad). However, the problem with this, is that there will be a lot requests which will expensive to me as I will have to pay for the requests to Parse so I want to minimise these queries.
Currently, the best thing I can think of is to check once a day at midnight for example but this doesn't seem very seamless.
Is there a better way of doing this?
For starters consider how stale you are willing to allow an app's view of the world to be and cache the response that long. If a user views that screen every 30 seconds you might only want to actually check with the server 5 minutes after the last successful response (or the last response which had 0 follow requests).
You might consider switching from this sort of "pull" polling where the client decides when to ask the server if anything has changed to a "push" model where the server can inform the client when a change occurs. For example you can send a silent background push notification to a user's devices when they have a follow request, the app can then respond by performing your existing query.
You might still want polling or user triggered requests (like a "pull to refresh" gesture) as a fallback for missed notifications or devices with notifications disabled but you should be able to drastically reduce request volume.
We (a local hackerspace) have a Tumblr blog and wanted to make ourselves a Facebook page. Before going live we wanted to import all our Tumblr content to Facebook so our fans on Facebook can browse it here as well. For this I have made an app that reads all the posts from our Tumblr blog and publishes them to our new Facebook page (backdating those posts as well). Here's my problem: after the app does about ~130 re-posts (~260 operations: publish + backdate) I start getting an error:
Received Facebook error response of type OAuthException: It looks like you were misusing this feature by going too fast. You’ve been blocked from using it.
Learn more about blocks in the Help Center. (code 368, subcode 1390008)
The block is gone the next day, but after a similar amount of operations it's back. After a couple of hours later, when the block is gone again, I introduced 6 second delays between operations, but that didn't help and after 19 re-posts I'm blocked again. Some facts:
I am publishing posts to a feed of (yet) unpublished page I am the (only) owner of.
The app is a standalone JAVA application and uses restfb to work with Facebook.
The line that is causing the error: facebookClient.publish("me/feed", FacebookType.class, params.toArray(new Parameter[0]));
All publish operations contain a link, mostly to respective posts on out Tumblr. Some contain message, caption or a name (depending on post type).
I need to re-post ~900 posts from Tumblr, I have done ~250 so far. When over, I will likely put in on server, scheduled, to keep syncing single new posts.
This app is not meant to be used publicly, it is rather a personal utility (but the code will be posted to GitHub, should anybody need it).
This is my first experience with Facebook API and I wasn't able to find a place where I could officially address them with this question. I could proceed by doing 100 posts/day, but I'm afraid I will eventually get banned for good, even though I don't feel like doing anything wrong.
I haven't put any more code here, as the code itself does not seem to be a problem, but rather the rate at which it is executed.
So, should I proceed with 100 posts/day and hope I won't be banned, or is there another "correct" way of dealing with this?
Thanks in advance!
I'm answering a bit late but I just had this problem too so I did some research : it seems that besides the rate limits shown in Facebook docs, there's also a much more limited and opaque rate for POST requests to limit spam.
It's not clearly set but it could depend on your relationship to the page you're writing to (admin or not), if you post to multiple pages and finally if you post too quickly.
To answer the question, it seems that it would have been okay if you had done like 1 post per minute or less.
I think you exceed the rate limiting for your user Id.
- Your app can make 200 calls per hour per user in aggregate. As an
example, if your app has 100 users, this means that your app can make
20,000 calls. One user could make 19,000 of those calls and another
could make 1,000, so this isn't a per-user limit. It's a per-app
limit
- That hour is a sliding window, updated every few minutes
- If your app is rate limited, all calls for that app will be limited, not
just for a specific user
- The number of users your app has is the
average daily active users of your app, plus today's new logins
Check this: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
It looks like you were misusing this feature by going too fast. You’ve been blocked from using it.
Learn more about blocks in the Help Center.
If you think you're seeing this by mistake, please let us know.
I am developing a chat robot that works with private messages on facebook. The person sends a private message to a page that I own, and then I will send an answer for each message.
Everything is working, but I need to be sure facebook won't complain about the amount of messages I will send. This application will receive a lot of interactions at the same time, but in some early tests one of my messages were received like that:
http://cl.ly/image/1C1n0Z2L0R05
I am now using Batch Requests to send all messages, on an interval of 15s.
Do someone know some way to test it with multiple users and multiple messages at the same time? How the process of identification of spam messages work on facebook? How many messages can I send at the same time and in what time range to prevent that kind of behaviour?
Thanks.
There is no set limit or guideline on volume.
But really volume should not be the issue. There's a huge number of factors that is taken into account to determine if a message is spam... too many to discuss here. But you can assume basics: the content of the messages, the volume per user in a given time period, the content variation per user, has this app been flagged as spammy before, by how many users, etc. I would say its reasonable to assume your test user is probably going to be triggered as spammy because you're likely using it far far more than the average user would.
So, in short: it depends entirely on what exactly you're doing every 15 seconds.
Tip (although I cannot verify it): if you are trying to batch send a message to a number of users at once, without them very recently contacting you, you're probably gonna be flagged as spammy.
Here the scenario.
I have an app the requests each new user read_stream and publish_actions permissions.
The app is subscribed to user->feed real time updates.
The app publishes a post on the user_fuid/feed everytime the user performs a specific action.
I need the real time updates system to post to my callback whenever the user deletes (or, better, deletes or hides) one of the posts published by my app.
Is that possible?
If so, is that the optimal solution or can I do it better (like with less permissions, higher performances, etc.)?
So far, I've received notifications upon posting and liking. But I quite have the feeling that the real time updates system reacts on an paradigm of accretion of the graph but do not notifies removals. Am I right?
Jeff Lindsay, who coined the term 'webhook', said that the difference between webhook and http callback is that webhooks are user-defined. I think I understand what he meant, but I was thinking about it and I asked myself, can webhooks be effectively used by regular users (I mean: non-developers)?
Usually people don't have a clue how the internet works, they don't know what http is, terms like URL, callback, or request-response don't say anything to them. I've heard that many people do not know the difference between a web browser and a web site, they think that internet really starts at google.com and they type in all urls in the google search box... I mean, what's the use of webhooks when you're not a developer?
Do you think services like AlertGrid make sense? It's a webhook consumer that you can configure to dispatch alerts (SMS, phone, email) either when the callback is NOT received in x amount of time, or when the received data meets user-defined condition, plus it does some data visualization. We wanted it to make webhooks usable for non-developers. But still it requires an initial integration by someone who at least knows how to configure the source to send the webhook events. In many cases it only takes pasting an url to a textbox, but it seems to be beyond the skills of a typical user.
So, are the webhook doomed to be used by software developers only, or is there a chance that millions of Facebook or Twitter users will start making use of them somehow?
I think that something implemented using Webhooks can be made very user friendly.
Suppose Stack Exchange allowed users to define a webhook that would be notified whenever you earned a badge. You could supply a custom URL, or there could be simple buttons to click that would set it up for your Facebook or Twitter account. It could be as simple as the Facebook Like button.
YES I think this is a great idea. It's actually something I designed in my head a couple months ago and didn't think the product existed.
Webhooks are extremely powerful and having a 'service bus' aggregate/manage/dispatch these callbacks is extremely compelling to me.
I think that we are a long way from the general public consuming webhooks in any sort of meaningful way but I don't see why not. I remember when RSS was a 'developer' only technology.
Thanks for the link. I'll be digging in more this weekend.