Uploaded image for project: 'ListenBrainz'
  1. ListenBrainz
  2. LB-574

Statistics Endpoints: avoid huge results

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Normal Normal
    • None
    • API
    • None

      When I query my artist stats, I get a JSON payload of nearly a megabyte, containing 7500+ entries. That seems a waste of resources; the user is generally unlikely to want to see that many results.

      On the other hand, if I specify a limit of 10, I am not told there are 7500+ entries available.

      I would strongly recommend:

      1. adding an extra field (max_count? total?) containing the total number of available items
      2. defaulting the count to some documented constant (10, 40, and 100 all seem like viable music-related defaults)
      3. limit the range of count (0-250? 0-500?) so that users need to perform multiple (rate-limited) requests instead of being able to grab one giant payload (a count of 0 could be used just to get the max count and last-update timestamp)

          [LB-574] Statistics Endpoints: avoid huge results

          Param Singh added a comment -

          We've added a `total_artist_count` field. It was done in a different PR.

          Param Singh added a comment - We've added a `total_artist_count` field. It was done in a different PR.

          Tim Van Holder added a comment -

          The PR does not seem to add the extra field to the result, indicating how many results there are (so to see the "last 50", I would have to scroll through results all the way to the end).

          As an alternative to the field, I suppose you could also handle negative offsets as offsets from the end (and so a request for offset -1 would return a single result, with the offset set to the number of results.

          Tim Van Holder added a comment - The PR does not seem to add the extra field to the result, indicating how many results there are (so to see the "last 50", I would have to scroll through results all the way to the end). As an alternative to the field, I suppose you could also handle negative offsets as offsets from the end (and so a request for offset -1 would return a single result, with the offset set to the number of results.

          GitHub Bot added a comment -

          See code changes in pull request #844 submitted by ishaanshah.

          GitHub Bot added a comment - See code changes in pull request #844 submitted by ishaanshah .

            ishaanshah Ishaan Shah
            zastai Tim Van Holder
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:

                Version Package