Limit to API calls within cloud script?
-
Hi! Just a quick question:
I'm writing a cloud script for updating user entities in bulk from my client, and I'm wondering if there is a limit to how many API calls (updateEntity) I can do within this script?
Even if there isn't a limit, I'd welcome suggestions about what would be a sensible limit to impose on myself
-
There's not a hard limit - but brainCloud does encourage devs to work with us to keep scripts tight and efficient. That's the biggest reason why we charge per API call - the tighter and more efficient you can keep things, the less your app usage will cost you.
Scripts are more efficient than full-blown API calls - so they are encouraged.
brainCloud charges:
- 1 API Count to call the script
- You get 3 API calls from the script for free
- From then on, each API call is just 1/2 an API count
All-in-all, doing a bunch of operations from a script (instead of remotely from the client) is:
- A better user experience (the end-user doesn't have to wait for all the individual requests and responses to go back and forth to/from the remote device)
- Uses less server processing (receiving and breaking apart the messages is one of the bigger loads on the system)
- Costs the dev less (due to the API count rules above)
It's win:win:win!
Okay though - back to your question
There aren't any specific limits to the # of API calls you can make. We do have watchdog timers on scripts, to help ensure that things aren't running awry. The default timeout is 10 seconds (though honestly most scripts take < 100ms to run).
That said, of course, the more calls you make - the more your scripts will cost you - and the more time your customers spend waiting for the script's response.
Also, client timeouts can sometimes interfere. If you've raised the timeout on your script to 20 seconds to allow it to do some big operation, but your client timeouts are set to the default 15 seconds - then often your client will timeout before the script is complete, and you'll cause extra server traffic as your client automatically retries.
Another observation - must issues folks have with scripts has more to do with how they are accessing data, than the script itself. It's less about the API counts, and more about how you're using Entities - especially Global Entities, whose performance can really slow down if you've got too many of them (i.e entering the thousands) or have entities being written to by too many people concurrently.
Okay - let me see if I can boil this down to a few straight-forward points:
- There are no specific limits on the # of API calls made from scripts
- Apps are charged per API call, so keeping the number lower is best for all
- Scripts are however more efficient (and less expensive) than making the calls from the client, so when in doubt, extra calls in scripts better than extra calls from the client
- The real thing to watch for is efficient data access. Global Entities are to be used carefully - User Entities and Custom Entities with proper indexes are much, much safer.
- In general, keep scripts to well under 1 second execution time for best performance.
- Scripts with 3-8 API calls generally perform best (totally off the top of my head). If you're getting 20+ API calls you probably want to rethink the script, unless it's some sort of periodic background script (i.e. scheduled, not from the client).
Hope that helps?
Paul.
-
@Paul-Winterhalder That's very helpful, thanks! I was thinking about updating 5-10 user entities in one go, so it seems my estimation wasn't half bad!
-
@Paul-Winterhalder
There should be a bulk update api calls with some limits to not misuse. For example its quite often to perform perform bulk delete or edit objects and if we have 1000s of objects then even dividing with 3 doesnt help that much cost wise. -
Hi Ali,
Can you describe your use case a bit more?
Paul.
-
@Paul-Winterhalder Lets suppose , i want to delete 100 entities
currently i have to call delete entity api 100 times = 100 apis
so a bulk api that "actually cost 1 api" which takes a entities_ids array for bulk deletion. you can have a max limit of 100 ids to keep it fair.Similarly a bulk api that creates multiple objects in single call and still cost 1 api and takes array of json objects instead of just one object.
-
Hi Ali,
What types of entities are you using in this use case.
Definitely makes sense to me to add something for this to Custom Entities. User Entities and Global Entities would be lower on my priority scale...
Rationale - we're encouraging folks with large numbers of entities to move to Custom Entities, which perform much, much better. [That plus the normal limited resources rationale.]
Thoughts?
Paul.
-
@Paul-Winterhalder Even though in current projects im using global entities as i started it way before custom entities; however i'd welcome these bulk api improvments for custom entities only. As my next project which is focus around user generated content,'d make a great use of it.
-
Sounds good Ali - thanks for the confirmation!
Paul.
