Hello,
what is the best practise to gather additional UserData from Users retrieved by the Client.GetFriendList command ?
I saved the avatar and more infos in the UserData, so i need to get them.
Should i fire a GetUserData Query for each friend ? Or is there something like GetUserSData, so i can query more than one PlayFabID ?
If i would make a cloud script to bundle everything, i would call more than 10 API calls.
Any Ideas ?
Sorry, but neither of those are options. Regardless of whether the calls are made from a client, a custom game server, or Cloud Script, they all hit our API servers the same way. That's the nature of highly scalable systems - the Cloud Script and API services aren't all running on a single machine, as it would not be able to scale effectively for very large user bases. And while occasional bursts of several calls are okay, so long as the average for all calls across a session are kept to a reasonable level, dozens (and potentially hundreds) of calls to get user data at once would be outside our fair use policy.
What I would recommend is to provide the user with the info you get back from GetFriendsList, using the tagging system to get some extra info into the data you get, and query to retrieve any extra data (avatars, etc.) on a "this user" screen if the player clicks on an individual friend (expand the listing to show the rest).
What if i limit (in my game) the friendlist to 9 users ? (would be reasonable amount for my game, most ppl will have 5-6 friends or less)
Would it be in the fair use policy if i call getFriendList (retrieve maximal 9 playerFabIds), and then call GetUserData with 2 keys for each friend, that would be in the 10API calls segment ?
I cant rly use the tagging system in my situation, since i need to get the infos from the other user.
Without the avatar my friendlist would be rly ugly :(
The issue is going to be around the total volume of requests and data you're asking for - that's why we designed our limits the way we did, to ensure that no title can impact any other title in our service. So if your call rates exceed our fair use limits, you'll either start getting errors back or delays in responses (we're moving as much towards delays wherever possible). In the case of Cloud Script, if the total number of calls adds up to 10, that would be fine, assuming you're not calling Cloud Script calls one after the other in rapid succession on the client. Again, think of it as needing to keep your request rate for a single player down to less than 1 per second on average over the player's session, regardless of the source (client, Cloud Script, or custom game server).
Thank you for your detailed answer !
But sorry for asking again, i just want to make sure i choose the bset solution within your fair use policy.
In the usage limits it says for shared group data "10 per player, up to 100 keys each". What if i have no players attached ? Would it be a solution to save the avatars from all players in a shared group and get them with the GetSharedGroupData with keys according to their PlayFabIds ? What is the performance of a shared group ? Is it build for large amounts of values or for small group of players like Clans ?
My last solution would be a custom build SQL table on my AWS server, but that would mean saving redudant Data and keeping them in sync.
Are there any plans on publishing or developing an API to retrieve specific UserData keys from several players at once ? I think that would allow of cool things to do !
Thank you again !
No, unfortunately, that would not work. With backend services, there are two types of data - one which is cached and distributed across multiple servers, so that all players can access it, like Title Data, and one which is non-cached and intended for update by the individual players.
Shared Group Data is a place where a subset of players, like a clan, can share some data which is designed to be updated by individual players, Title Data would be an example of data which is intended for access by all players. But the point with those global data elements is that they're updated infrequently, as they need to be cached and distributed (meaning that on update there's going to be a small update period in which not all players will see the same thing - in our system, that's about one second).
Since Shared Group Data is not a distributed data type, you would have all players attempting to access the same data on a single server, which would result in hitting data table read limits and so delays in getting the data to players (at large scale, that is).
We do plan to offer some specific means for accessing data across many players, like multiple columns for leaderboards. In each case, those will be targeted at specific common case needs in our community, but they may well be useful for more broad-usage cases.
