Don't discourage modulation by charging per in-house calls
-
Seems like the practice I've read is to have 1 giant master script to save API calls. This encourages INCREDIBLY bad practice for the overall architecture for all devs (and makes senior devs that know not to do this cringe and scratch the wall as if watching a horror film).
How about finding a different way to charge users to compensate this? Perhaps merge it elsewhere - this wasn't even good practice in the geocities/angelfire days. This... is just unacceptable from a modern BaaS, in my professional opinion. Why are in-house API calls even charged extra at all? Shouldn't it just be from client to server -> Do as many calls as you want since you're charged per CPU anyway (iirc?) -> Return the final result.
For example, if I have to CallSteamAPI() and CallDiscordAPI() in ONE script, that's just really horrible practice ... but seems like BC users are forced to?
-
Hi,
brainCloud doesn't really force anyone to do anything - we are a toolbox to be used to build your game.
And we certainly wouldn't try to force bad code.
The recommendation to bundle API calls together into scripts reflect the reality that:
- Deserializing a request from a client takes significant time+processing. Processing API calls from within a script is definitely less CPU intensive than receiving and processing them one-at-a-time - thus our API Count pricing reflects that
- There is also a perceivable performance benefit to the end-user. A script that performs a number of API calls from within will outperform those same API calls called directly from the client.
So - we see it as win:win:win - better user experience, better experience for the end-user, and less cost to you.
We encourage you to organize your scripts as makes sense for your application. To help support this - brainCloud allows you to import script functions into your script to be called (
bridge.import()) - or to call other scripts directly (bridge.callScript()).As for why our pricing is elastic - that is so that the costs we incur from your app match the costs to you. This puts us both on the same side when optimizing your app. The lighter your app, the lower the costs on our end, and we pass those savings onto you!
Hope that helps!
Paul.
-
My only complaint i have about the cloud-code API policy is that after the first 3 API calls, each extra API call should be charged at a rate of 0.33 instead of 0.5. Basically with the cloud code API policy, Braincloud charges 3.33$ for the first million and 5$ for every extra million API calls in cloud code.
i.e In a Cloud script with 9 'Pure' API calls that's called 333.333 times within a month (total: ~3 million 'pure' API Calls) the first million is basically charged at 3.33$ and the other 2 millions are charged at 5$. So total charge would be: 13.33$ which is true since this cloud script counts as 4 actual API Calls (total: 1,333,332 API calls).
But if my use-case allowed, i could break this Cloud Script in 3 different Cloud Scripts (3 api calls each) and call them from the client in order and using the return result as input to the next cloud-script to continue exactly where i left it. Now that would be 999.999 total API calls and i just saved for myself 3.33$ but in reality the backend did a lot more work.
Please do consider my suggestion of reducing the API count rate at 0.33
-
@Panagiotis-Milios another problem is Pre and Post Hooks are treated/costed seperately. This should fall under the same 3 free api calls rules, so if i make a call to authenticate user, then prehook + authentace + post hook should b call as 1 + 2 free api calls rather than 3 seperate api calls defeating the purpose and benefits of using pre/post hooks.
I really hope BC listens to us
-
These points above are indeed good examples regarding "forcing bad practices":
If I have 3 free API calls after the API call, after the 3rd freebie, I can return it and call again for 1 core + 3 more that can branch off again. This is inefficient for BC, yet beneficial for end-users (thus, forcing bad practices since it costs and gives more if we avoid the pre and post hooks).
If a workaround to save API costs would be more work for the user, and costs more for BC, that's a lose-lose. If such a "hole" exists, shouldn't it be repriced for that consideration to make it the win-win you folks want it to be?
