breakout issue for this specific part of the overall "key handling improvement" workflow, initially defined in #71
key limiting:
#71 suggests we add a "platform features" column to the worker_oauth table where we store API keys. This would be for storing key pseudo-platforms (IE: the different request limits for each key type - gor github, these would be rest and graphql) these values would be used by keyman for rate limiting.
For the purposes of this issue, I would call this "rate limit groups" instead, and i think they belong in the internal implementation, alongside other information like the platform name/type, rather than in a DB table, since they are basically fixed information that changes with the API (and should therefore live in the implementation code).
Originally posted by @MoralCode in #293
This should be done as part of the code implementing each platforms API (and integrated into keyman so workers can fetch the right API keys/groups for what they are doing)
breakout issue for this specific part of the overall "key handling improvement" workflow, initially defined in #71
Originally posted by @MoralCode in #293
This should be done as part of the code implementing each platforms API (and integrated into keyman so workers can fetch the right API keys/groups for what they are doing)