Closed ezhevita closed 4 months ago
After brief evaluation, good stuff :+1:
I'd use this opportunity to refactor and reuse components as much as possible instead of bringing up our own ones:
readonly
field for keeping it, then adding appropriate getters/setters we care about reaching it. Moreover, the field can be public
which would allow plugin creators to extract other information from it without our hard mappings.uint RealAppID => Description.RealAppID
. I don't like our current code that does a lot of back and forth parsing/setting.[JsonIgnore]
, then add helper properties with getter and setters, annotate them as json-compatible, and add logic for each property to get/set appropriate value in underlying backing protobuf field. This way you'd have one "superclass" for asset and description, that'd still be compatible with both, being constructed from CM response (you pass received protobuf as constructor), as well as AWH json response (json serializer creates it, then calls setters for each helper property, effectively manipulating underlying protobuf without even realizing).Does that make sense to you? If yes, we don't need to worry about breaking changes much (for plugin creators), as such refactor is totally justified for future of the program.
Thanks a lot! :trophy:
Checklist
Changes
New functionality
None
Changed functionality
Inventory fetching now works using CM requests instead of web API, there are no rate-limits and it allows loading even 82k+ inventories in about 11 seconds.
Removed functionality
Fetching foreign inventories is no longer possible, however it wasn’t used in ASF anyway and it is rate-limited to hell ¯\_(ツ)_/¯
Additional info
This code was in production for about a year so it works pretty stable and Steam didn’t break anything in this time period. Also current implementation of
AdditionalProperties
is pretty awkward so any suggestions to improve it are welcome.