I'm currently developing a facebook App whose purpose is to
For a given page, list the last X posts
For each of said posts, list the last Y comments
For each of said posts, list the last W reactions (e.g. likes)
For the page as a whole, display the Z most active users considering the last X posts
The app is not yet published (And, since it'll only provide server to server communication, it might never be) and it currently has one admin and 4 test users.
I'm currently hitting rate limits for the comments endpoint, whereas I've never got any alert for the reactions endpoint.
The rate limit documentation says that some endpoints do not count for rate limiting, but it doesn't say which ones. So I assume that, in my case, only the comments API calls are eating my rate limit.
One approach I might consider to go over the rate limit is to create test apps for my app. They do have their own app-id and app-secret, and share the same app-scoped User ID namespace, so user IDs will be consistent and I'll be able to use both Apps to display aggregate data.
What I don't know is do test apps have their own rate limit?, or do they "eat" part of the production app rate limit?
I want to avoid creating the logic to rotate the App credentials on each call only to discover the rate is still the same.
Edit: I created a test app and hardcoded some calls to use its credentials. However, said calls aren't shown in test app's dashboard. I believe this would mean that its calls are attributed to the main app anyway.
Related
I'm a client side developer with little experience of server side, and I'm struggling to understand how to make a database-backed website without requiring users to login.
The usecase is fairly straightforward. The user lands on a website, uploads an image, and performs some processing to that image. Clicking 'share' POSTs JSON to my endpoint, stores it in a DB, and returns a unique URL in a textbox (eg, https://example.com/art/12345) which allows the user to share their artwork with others, or just to come back and do more editing later on.
What stops somebody from doing, POST <data> https://example.com/art 100 million times and filling my pay-as-you-go database?
I've seen examples of this link based method of sharing between users on plenty of sites but I don't understand how to stop abuse, or whether it is safe to just open up an API which allows writes to a database. I do not want users to have to login.
I believe the simplest method is having a quota, either by username for logged in users or by IP, if you don't require logins or only want to allow free usage to a certain point. Perhaps you could have a smaller quota for non-logged in users than for logged in users and even larger for paying users.
Your server side code that handles the POSTS and storing data into the database would have to take care of that. I'd add it to a user_data table on mine, making an additional column that tracks total space used. makes a todo
Then, when the user adds new data, increase the total space used. When they delete old data (I have versioned web pages so that eventually, the user will be able to rollback to previous versions) then the space used decreases. Having another page to look at to see where they're using space makes deciding what to delete to stay under a quota of X MB's/GB's/TB's/etc easier or maybe just an /api/delete_old_pages or notes or comments or all of the above.
my question is simple, we need an app to manage a large amount of Facebook ads/adsets on our own single account.
Basic operations, like for example setting a daily budget for all adsets in one shot, instead of manually doing it via facebook interface.
The issue is that we are reaching the API limits pretty fast, as we can have even 50-100 adsets in one campaign. I am hitting the API limit simply by listing them sometimes.
I saw in the Facebook App advanced settings that you can add an Facebook Ad account ID, or a Business account, would that help with the limits?
Or even better, is this even possible? Handling large amount of ads? We have a big budget and all, but it's getting tedious to micromanage large amount of ads.
The rate limit per adaccount is heavier limited if you are in development than in basics. In the basics level you can also have three instead of one system users, which would probably mean (correct me if I am wrong) that you can alternate between three tokens and thus get more api calls.
It is also worth to note that updating existing ads/adsets/campaigns is 10-100 times more expensive than creating new ones. You will also get the rate limit error if you change daily budget or similar more than four times a day, so that might be a problem during testing.
I know that fb have made available some documentation about the requests limits to the api https://developers.facebook.com/docs/marketing-api/api-rate-limiting,
but it is not clear how each api call is calculated...
i.e, If I want to get stats for ~10,000 adsets, how can I evenly space the time between the calls ?
The best answer i could find for this question from another SO thread -
"After some testing and discussion with the Facebook platform team, there is no official limit I'm aware of or can find in the documentation. However, I've found 600 calls per 600 seconds, per token & per IP to be about where they stop you. I've also seen some application based rate limiting but don't have any numbers.
As a general rule, one call per second should not get rate limited. On the surface this seems very restrictive but remember you can batch certain calls and use the subscription API to get changes."
Source - What's the Facebook's Graph API call limit?
Official Doc-: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
Rate limits are imposed on each app. The rate limiting tool gives you information about how close your app is to being throttled. Click on any sample to get more detail on the types of utilization.
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. This isn't a per-user limit, so one user could make 19,000 of those calls and another could make 1,000. This limit is calculated based on the number of calls made in the previous hour.
Source-: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
Heavily rate-limited per ad account. For development only. Not for production apps running for live advertisers.
I need your expert advice on this one.
I have been asked to analyse a potential Facebook application.
This application is a parental monitoring for kids accounts. Basically it will search a kid status message for specific keywords amongst others things. And this application will alert the parents when it finds something.
Of course this application will have a valid token to access the kid's data. This is not a tool to spy on the kid.
I am using the Graph API coupled with the 'since' keyword to get the last updates. It's working fine with a single user.
My question is about scalability.
How should I get updates of a huge number of kids to monitor? (between 10,000 and 100,000 accounts)
And for each kids I have to monitor status messages, videos, images, friend, friends' status messages...
Here are some numbers:
~2.1M requests each day to get hourly updates of 10,000 kids' account.
~57.8M requests each day to get hourly updates of 10,000 kids'account plus their friends', with an average of 40 friends each.
And as I read here, it would be limited.
So what do you reckon?
ps: Maybe with real-time updates I won't have this problem or would it be worse?
Yes I would subscribe to real-time updates so as an account gets updated you get a callback and then you get the latest updates. This would avoid the overhead of constantly polling accounts for updates. You will need to get an offline_access token for this to work as well.
How do you get the total number of users in a Google Apps Domain? I'm aware of the "Retrieve All Users in Domain" call using the Google Provisioning API, but I'd rather not execute such an intensive call just to count up all the users. Is there a simpler way to do this?
I found a solution that isn't as resource-heavy as retrieving all users: The Google Reporting API can be used to get the total number of accounts in a Google Apps domain.
The Google Apps Admin Settings API allows you to retrieve both the current and maximum number of users in the domain:
https://developers.google.com/google-apps/admin-settings/#retrieving_the_current_number_of_users_in_a_domain
this would be preferable to the reports API as it's both lower in traffic and it's closer to real time (reports are only updated every 24 hours so it won't take into account users recently added).
You could try "Retrieve All Nicknames in Domain" which could save some bandwidth as it hopefully really only retrieves the nicknames, although I think this won't get you the exact count because "Retrieve All Nicknames for a User" seems to imply that a user can have multiple nicknames.
If you've got some test domain, also assure that retrieving all users really is too much overhead and keep in mind that depending on what you want to do, you can perhaps build some kind of cache around it that only does a full request after the cache is older than X.