With discord.py 2.0 around the corner, one of the more interesting things we could do with it is autocomplete.
I have some performance concerns:
We need to stay within 60 requests / 60 seconds and no more than 10,000 requests per day. Autocomplete could take a big chunk out of those allotments.
Debounce on the autocomplete is apparently 300 ms. If we don't throttle that, it could still be OK in bursts. we might want to throttle that back to 1000 ms or even more, but the more you delay it, the more jittery and broken it will look.
Caching would help, but I have doubts that enough people would type the same things in the course of a short period of time to make that very useful.
The ultimate caching solution, downloading the whole taxonomy and keeping it up-to-date so that we don't even need to hit the API when handling the autocomplete is a lot of work for very little gain:
1.3 million records @ 60 per 60s, 500 per page would take about 40 minutes
there's no way through the API to request only updated records
not to mention the added complexity here
Some back-of-napkin figuring
1000 name lookups a day and let's say, 5 autocompletes per request, for 5000 requests a day.
That's half the daily quota!
We might want to build in some sort of safety measure like a separate rate limiting pool limiting the overal total # of requests autocomplete can handle per day to some fraction of the full 10,000 (like no more than half?)
We could try it without optimization and keep some stats to see if it's actually making an appreciable dent in our overall capacity to do API requests.
This is an ambitious feature with enough challenges to it that we probably want to check it with the iNat devs before proceeding.
With discord.py 2.0 around the corner, one of the more interesting things we could do with it is autocomplete.
I have some performance concerns: