The shape of data returned by pubg-fetch is very convenient in the case of season stats. Maybe the data we care about is nested a little deeply, but that's the nature of an API many times. However, you can see that it is simple to walk through the map and start handling the meaningful data. To my mind, one valuable benefit of this result is how each game mode has its own child map of stats.
(get-in (pubg-clj.api/pubg-fetch
{:url
"https://api.pubg.com/shards/steam/players/<ACCOUNT-ID>/seasons/division.bro.official.pc-2018-13",
:api-key my-api-key})
[:body :data :attributes :game-mode-stats])
=>
{:duo
{:kills 0,
:boosts 0,
:team-kills 0,
<SNIP-STATS...>},
:duo-fpp
{:kills 0,
:boosts 0,
:team-kills 0,
<SNIP-STATS...>},
<SNIP-MODES...>}Using the fetch-player-season-stats function threads the data through the player-season-stats-parse function, which then invokes pack-game-mode-stats, burying the game mode inside the related map of its stats.
#:pubg.player{:id "<ACCOUNT-ID>",
:season-stats
[{:pubg.season.stats/round-most-kills 0,
:pubg.season.stats/losses 0,
:pubg.season.stats/time-survived 0,
:pubg.season.stats/walk-distance 0,
:pubg.season.stats/best-rank-point nil,
:pubg.season.stats/rank-points-title "",
:pubg/game-mode "duo",
<SNIP-DUO-STATS...>},
{<SNIP-MODES...>}]} There are two issues here I think. First, it is no longer convenient to get to the game modes. Having the modes buried this way forces the client to resort to a filter matching against :pubg/game-mode to extract those stats by mode. This feels contrary to idiomatic keys as functions of their maps.
Second, it's subtle, but the way this is parsed and packed together results in the value of :pubg.player/season-stats now becoming a vector of maps. This further complicates how we can get to the data for each mode by forcing clients to extract the maps from the vector first. This sneaks up on the user and is very surprising.
I've been trying to understand the rationale for this behavior. Do you have some insight?
The shape of data returned by
pubg-fetchis very convenient in the case of season stats. Maybe the data we care about is nested a little deeply, but that's the nature of an API many times. However, you can see that it is simple to walk through the map and start handling the meaningful data. To my mind, one valuable benefit of this result is how each game mode has its own child map of stats.Using the
fetch-player-season-statsfunction threads the data through theplayer-season-stats-parsefunction, which then invokespack-game-mode-stats, burying the game mode inside the related map of its stats.#:pubg.player{:id "<ACCOUNT-ID>", :season-stats [{:pubg.season.stats/round-most-kills 0, :pubg.season.stats/losses 0, :pubg.season.stats/time-survived 0, :pubg.season.stats/walk-distance 0, :pubg.season.stats/best-rank-point nil, :pubg.season.stats/rank-points-title "", :pubg/game-mode "duo", <SNIP-DUO-STATS...>}, {<SNIP-MODES...>}]}There are two issues here I think. First, it is no longer convenient to get to the game modes. Having the modes buried this way forces the client to resort to a
filtermatching against:pubg/game-modeto extract those stats by mode. This feels contrary to idiomatic keys as functions of their maps.Second, it's subtle, but the way this is parsed and packed together results in the value of
:pubg.player/season-statsnow becoming a vector of maps. This further complicates how we can get to the data for each mode by forcing clients to extract the maps from the vector first. This sneaks up on the user and is very surprising.I've been trying to understand the rationale for this behavior. Do you have some insight?