Closed jaraco closed 5 years ago
I've just started running into this issue, has anyone made a change/PR to attempt to address this?
@jaraco @mdove Sorry for my late response. I think it's better to be cached on the client side as some users may not want this caching behaviour or need something entirely different. For instance you may just want to cache the IDs where others may want to cache the whole response. I don't see caching functionality to become a part of the library.
For other people who might be interested in implementing their own caching solution, here's a quick example:
from slacker import Users
class CachedUsers(Users):
def __init__(self, *args, **kwargs):
super(Users, self).__init__(*args, **kwargs)
self.user_ids = {}
def get_user_id(self, user_name):
user_id = self.user_ids.get(user_name)
if not user_id:
user_id = super().get_user_id(user_name)
self.user_ids[user_name] = user_id
return user_id
We're using
slacker.get_user_id
in this code, which runs for every message transmitted by our bot. Anytime a@
appears in the output, it searches for a user id for that value. This causes many invocations toget_user_id
which in turn hits the rate limiting in Slack:My instinct is that
get_user_id
should probably cache responses with a method cache, such thatget_user_id
for a given ID doesn't need to re-query the list of users. That should drastically reduce the number of requests in a busy system.Is this behavior something this project might consider, or should the client (us) add the caching themselves?