Monitoring | Global Monitoring | Global Entities.

Note - if your app is live, you need to unlock it first. You'll see a bit [+] button to the right of the Bulk actions drop-down.

Good luck!

Paul.

Hi Travis,

Hmm - 100Kb is not appropriate for Global Properties. We don't recommend more than 3-4Kb of JSON in a global property, for example.
Perfect, thanks. Good to know a rough size to work with.

Global Entities are fine for tuning data - just ensure that you can look up your entities using the entityIndexedId. That id is essential for fast lookup.

I think the id lookup restriction will be fine, and since they are read-only, I won't need to worry about write contention.

One more question, I wa hunting around the dashboard, and I couldn't find a place to create a global entity. What am I missing?

Thanks,
Travis

Hmm - 100Kb is not appropriate for Global Properties. We don't recommend more than 3-4Kb of JSON in a global property, for example.

That said - you can have a bunch of global properties. Lots of folks use them for their tuning data - but more as individual key+value pairs - and smaller JSON blobs. So you can definitely store tuning data there - in more atomic form.

Global Entities are fine for tuning data - just ensure that you can look up your entities using the entityIndexedId. That id is essential for fast lookup.

Global Entities are not good for transactional data or player-owned data - cause the numbers group to large. For those, you definitely want Custom Entities. But if you are talking about reference (i.e. read-only) data with known ids for quick look-ups, then Global Entities should work fine for you.

Hope that helps!

Paul.

Based on the description of your use case, I'd recommend you to use custom entities, which natively have the user access control (ACL) configured. And check out this article about some size limits on entities in case you haven't see it. http://help.getbraincloud.com/en/articles/3472603-what-are-the-size-limits-on-user-entities

I've read that article, but it doesn't talk specifically about Global Properties.

What is the downside of going with Global Properties, or Global Entities?

As far as ACL goes, I was planning on blacklisting most BrainCloud client apis (more likely whitelisting apis) and returning the data I want to go to the client with custom cloud code.

Hi Travis,

You have a few options:

• Global Entities - simple, basic API - but not very scalable. Definitely make sure you have < 1000 entities.
• Un-owned Custom Entities - more scalable, custom indexes, etc. Requires plus plan
• Global Properties - store simple strings and smaller JSON objects

Thanks Paul,

Question: with Global Properties or any of these other approaches, what are some performance implications or limits to keep in mind? Is 100kb of json (stringified) per property slot too large?

I am looking for a place to store my global app "tuning" data. The tuning is broken up into logical sections (for example: Clash Royale style loot drop tuning, world progression tuning etc.). The largest sample tuning section I have right now is around 100kb of json data. Is that too large?

The tuning would be "read-only" from the client/players perspective: neither the client, nor cloud code could modify the tuning. Some of the tuning would be sent down to the client, probably via a custom cloud script call (getClientTuning), and some of the of the tuning would be exclusive to the server (drop rates).

I have been playing around with this idea in Cloud Code, and it would look something like this:

    var tuning = {}
    tuning.lootbox= JSON.parse(bridge.getGlobalProperty('lootbox'));
    tuning.cards = JSON.parse(bridge.getGlobalProperty('cards'));
    tuning.levels= JSON.parse(bridge.getGlobalProperty('levels'));

    DropItems(tuning);

Hope this makes some sense!
Travis

You have a few options:

• Global Entities - simple, basic API - but not very scalable. Definitely make sure you have < 1000 entities.
• Un-owned Custom Entities - more scalable, custom indexes, etc. Requires plus plan
• Global Properties - store simple strings and smaller JSON objects

Those would be the main options. And yes - accessing them uses API calls - but remember, you get 3 free API calls in a script - and every call from then on is just 1/2 a count.

So if you have a script that makes say 5 API calls - it will actually only cost you 2 API counts: 1 to call the script, 3 are free, and the remaining 2 calls are 1/2 each.

Hope that helps!

Paul.