I'm developing an app that shows the score of sports-related matches in real-time. I'm using an API (JSON format) to fetch the score and to do this, I'm using a stream builder to stream the score and using a timer to call the API after every 5 seconds, so I can always show the updated score without user-initiated refresh
But I think this is not an efficient way from the perspective of the server and secondly, if I go with a paid API that provides limited no. of requests, then I would exceed the no. of API requests very shortly. So what is the better way to do it?
and one last question, this question may sound silly, so pardon me. If I go with a paid API that provides limited no. of request (Let's say 1000 API requests per hour)
and assume, 10 users are using my application to see the score, does that mean 10 API request would be deducted after a specified time period (5 seconds), or would it be considered only one?
Related
I have a Google smart home app released that supports various light bulb brands. I have a user with 5 Phillip Hue light bulbs and there are approximately 1360 query state requests per day for the 5 bulbs. Is this frequency of query requests common and expected for all devices?
That's one query request every ~5 minutes.
https://developers.google.com/actions/smarthome/develop/process-intents#QUERY
It is normal for Google to periodically send QUERY intents to your service to ensure that the data in Home Graph is up to date. You can mitigate this process by making sure that you have implemented Report State to publish all relevant state changes to Google in real time, as this also directly updates the state in Home Graph.
The actual frequency is a bit more difficult to pin down as it relates to not only how often you report state for devices, but also user activity on those devices. Generally speaking, the more often you report state to Google the less you should see QUERY polling.
We are also actively working on ways to reduce the need for QUERY polling, so in the future you should see the frequency of this reduced so long as you have Report State implemented for all your users' devices.
I have to create script to create adsets and ads for a facebook campaign and I have to do it for a lot of items. For now, i can create every needed entity but there is a big problem, the rate limit. I reach it pretty quick (I can create like 15 items before getting a rate limit exception) and this is very limitating, creating eveything by hand is actually much faster... I want to apply to the next level of rate limitation but I can't. One of my coworker contacted someone from facebook and we were told we did not make any API call using my app ID. Since I am able to create a campaigns, adsets, ads... and we can see those in power editor I don't understand what is going on.
What my dashboard looks like
We will need to be able to create everything using the API really soon so, after some research, I try asking the question here. Did I miss something when creating my app ?
You probably want to go through the official request to promote your app from a Basic level to a Standard level. The level for your app determines how heavily it is rate limited. Details here: https://developers.facebook.com/docs/marketing-api/access
It sounds as if you have not make your official request in app dashboard. It's possible we evaluated your number of API calls before you reached the threshold, or the data we are able to see on your API calls was from an earlier time period when you did not consistently reach the boundary.
You could also be hitting rate limits due to your error rates.
You can apply here, and if needed, reapply: https://www.facebook.com/business/standardadsapi?attachment_canonical_url=https%3A%2F%2Fwww.facebook.com%2Fbusiness%2Fstandardadsapi
I'm using the Core Reporting API (Reporting API V4).
Is there any way for me to determine the last time the data my query is returning was updated?
I'd like to be able to indicate whether the data being displayed was last updated several hours ago versus several minutes ago.
The API does respond with isDataGolden which tells you if the data will change again, if your website is small the data processing latency could be almost nothing.
From your question it sounds like you are more interested in not just if the data is stale but how stale. You could request the the ga:hour and ga:minute to find out when the last processed hit was recorded.
Note there is also the Realtime API which gives you a read of what is happening instantaneously.
My app is making exactly 268 calls per user ( not yet live) , but as per new facebook rate limitations its just 200 calls per user. So, caching and making less calls is one option or is there any other? and is that 200 calls per user, is really in implementation now?
Caching and making less calls is the only option. You can test if it´s just a guideline, i assume you can make a bit more too - but in general you should never even remotely hit the limit in a serious App. 200 calls per user per hour is a lot.
More information: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
I am the manager of an iOS application and it uses Google Places API. Right now I am limited to 100,000 requests and during our testing, one or two users could use up to 2000 requests per day (without autocomplete). This means that only about 50 to 200 people will be able to use the app per day before I run out of quota. I know I will need to fill out the uplift request form when the app launches to get more quota but I still feel that I will need a very large quota based on these test results. Can anyone help me with this issue?
Note: I do not want to launch the app until I know I will be able to get a larger quota.
First up, put your review request in sooner rather than later so I have time to review it and make sure it complies with our Terms of Service.
Secondly, how are your users burning 2k requests per day? Would caching results help you lower your request count?
I'm facing the same problem!
Is it possible to use Places library of the Google Maps Javascript API which gives the quota on each end user instead of an API key so that the quota will grow as user grows. See here
Theoretically I think it's possible to do that since it just need a webView or javascript runtime to use the library, but didn't see anyone seems to use this approach.