Tracking Issue for GetShopInventory Endpoint

[augenblick]

Issue for tracking progress on creation of an MVP version of the GetShopInventory endpoint of the SWCCG CardShop API

[augenblick]

@aaronaskew just trying to get some things scrawled down. I'm open to feedback on how to best leverage GitHub.

This information has been moved to the wiki

TODOs:

• Define MVP request object for GetShopInventory endpoint
• Define MVP response object for GetShopInventory endpoint
• Design how booster packs/booster boxes are built (MVP)

GetShopInventory Design:

NOTE: Items preceded by "[future:]" are beyond the scope of the MVP, and are to be removed and documented in a separate design document.

The initial CardShopInventory is generated when the app starts running.

• inventory maintained within application memory
• [future:] Inventory persists when server is stopped/restarted.

  When the GetShopInventory endpoint is called, a check of the existing inventory is made:

  • If inventory is below a given threshold, new inventory is added
  • [future:] threshold is configurable
  • If inventory is "stale" (last refresh or addition to inventory exceeds 2 days), 60% - 85% of inventory is removed and replaced with fresh inventory.
  • [future:] refresh timeframe and refresh parameters configurable in server configuration
  • [future:] implement some measure to ensure performance even if this endpoint is called regularly and in rapid succession.

The MVP inventory will consist of

• 6 booster boxes of varying sets
• card packs (available for single-pack purchase) consisting of 5% - 80% of booster box capacity from 5 different sets
• all products contain arbitrary pricing for now
• [future:] these parameters will be configurable in server configuration