Dash supports a feature for long-callbacks that checks the input-arguments and, if they've been used before, returns the cached output from a previous run of the function.
In our case, this would mean that, for a given list of repos for a visualization and the parameters the user sets, we could temporarily cache the visualization and not have to regenerate it.
There will inevitably be MANY visualizations with only minor changes between them cached (small parameter changes) but the user experience will be very good because, on average, they'll wait less time for the figure to be available.
This will also decrease read-load on the data cache because fewer round-trips for the same visualization will be required.
Dash's implementation of this feature is fairly simple, and Redis makes this ultra simple because we can auto-evict and set TTL on visualizations.
We can schedule a Redis instance for this with ~4GB of memory or less, with zero concern for data integrity or freshness.
Dash supports a feature for long-callbacks that checks the input-arguments and, if they've been used before, returns the cached output from a previous run of the function.
In our case, this would mean that, for a given list of repos for a visualization and the parameters the user sets, we could temporarily cache the visualization and not have to regenerate it.
There will inevitably be MANY visualizations with only minor changes between them cached (small parameter changes) but the user experience will be very good because, on average, they'll wait less time for the figure to be available.
This will also decrease read-load on the data cache because fewer round-trips for the same visualization will be required.
Dash's implementation of this feature is fairly simple, and Redis makes this ultra simple because we can auto-evict and set TTL on visualizations.
We can schedule a Redis instance for this with ~4GB of memory or less, with zero concern for data integrity or freshness.