andythorne
commented
8 years ago As we discussed on slack yesterday, getting a good understanding about how the app calls the API (orders, frequencies, etc) would be a good first step.
If we move to a queue, then that may solve some of the caching we're having to do (as, to niantic, it would not look like odd activity).
Unfortunately mapping API responses to an object is going to be a semi-manual task, unless our api models will reflect the api exactly (but then we may as well use a dict! (joke)).
niicojs
Right now I'm not satisfied with how the API wrapper is structured. For context, the way it currently works is the following:
Bot/plugin calls API method => wrapper determines which read-only calls are cached and strips them out => wrapper performs API call => wrapper parses response into objects => wrapper returns all objects.
It's not really a clean solution (just look at the parsing methods and the data objects) and I never really intended it to be one, just as a stopgap to prevent the overuse of dict accesses for API responses.
Any ideas on how this can be improved?