Hi @gyutaelee ,
Based on the current brainCloud's implementation, here are the answers to your questions:
Q1: Does the Pre-hook count as a separate CloudCode execution / API count?**
Yes. The Pre-hook counts as both a separate API call and a separate CloudCode script invocation. After running, the server publishes its own analytics event with operation "RUN_HOOK-Pre_VersionGate" that increments both counts.
Q2: Does bridge.getGlobalProperty() count as an API call?**
No. bridge.getGlobalProperty() is completely free. It reads directly from the cached Game object in memory and bypasses the API call tracking pipeline entirely.
Q3: Does the "first 3 free, then 0.5 each" rule apply to hook CloudCode scripts?**
Yes, the discount applies to internal calls from any script or hook within the session.
Q4: Pass-through case: usage count breakdown
- Client calls script.RUN: +1 API call
- Pre-hook executes: +1 API call
- bridge.getGlobalProperty() inside hook: free
- Original CloudCode script: +0 (covered by the original script.RUN request)
Total external API count: 2
Q5: Blocked case: usage count breakdown
- Client calls script.RUN: +1 API call
- Pre-hook executes: +1 API call
- bridge.getGlobalProperty() inside hook: 0 (free)
- Original script: +0 (does not run, server throws before invoking it when hook returns non-200)
Total external API count: 2
The blocked case costs the same as pass-through from an API-count perspective. The only savings is that the original script's internal bridge.callAPI() calls are avoided.
Q6: Could reading a Global Property on every script.RUN become a performance or cost concern?
Performance: No. getGlobalProperty() reads from an in-memory cached Game object (ConcurrentHashMap per node) with no DB query or network call.
Cost: The hook itself adds +1 API count to every script.RUN call that has the hook attached.
Q7: Recommended caching approach for frequently-read, rarely-changed property?
The cache is already in place, no additional caching needed. brainCloud stores the Game object (including all global properties) in an in-memory cache for each server node. Cross-node invalidation is handled automatically when a global property is updated in the portal. Using bridge.getGlobalProperty() is already the optimal pattern.
Q8: Portal metrics: what can be broken down separately?
- API Hook execution count: Partially available. Hooks appear within the CC script invocation counter; no hook-only counter exists.
- CloudCode script execution count: Available as CC Script Invocations, but includes hooks in the same counter.
- CloudCode internal API call count: Available as CC API Calls in the Monitoring dashboard.
- Global Property read count: Not tracked. No metric exists for this.
- but definitely supported.
