The /neighbors endpoint at the moment is quite slow (optimization efforts are ongiong), but the input and output data (i.e., the input being the token, and the output being the resulting neighbors over the years) are both small. Also, tokens are often reused by multiple users (e.g., "pandemic").
We've decided on implementing a Redis cache to save and return these token/response pairs, and to potentially warm it with a list of common words that people might query. The cache eviction policy hasn't been decided on yet, but will likely be least-frequently-used with either a maximum cap on the memory used or number of records.
We've also decided to allow the cache to be examined, so that the frontend could, for instance, check if a word is in the cache before firing off the /neighbors request, allowing it to customize the UI accordingly.
This is a nice-to-have, but a separate endpoint could provide general information about the cache, e.g. how full it is, and perhaps a list of most-frequently-used terms that could populate a list of example queries in the UI.
falquaddoomi
commented
2 years ago
The
/neighborsendpoint at the moment is quite slow (optimization efforts are ongiong), but the input and output data (i.e., the input being the token, and the output being the resulting neighbors over the years) are both small. Also, tokens are often reused by multiple users (e.g., "pandemic").We've decided on implementing a Redis cache to save and return these token/response pairs, and to potentially warm it with a list of common words that people might query. The cache eviction policy hasn't been decided on yet, but will likely be least-frequently-used with either a maximum cap on the memory used or number of records.
We've also decided to allow the cache to be examined, so that the frontend could, for instance, check if a word is in the cache before firing off the
/neighborsrequest, allowing it to customize the UI accordingly.This is a nice-to-have, but a separate endpoint could provide general information about the cache, e.g. how full it is, and perhaps a list of most-frequently-used terms that could populate a list of example queries in the UI.