[Spike] Use Flask-Caching for shared caching - prototype 1

[lingyielia]

Description

• Allow no caching as default
• Allow user to use other caching options when launching the dashboard
• Caching is enabled on original data
• Allow workers to share caching objects
• a simple example on how to remove certain cache objects using custom actions @petar-qb

New features

• a simple example on how to clear the entire cache @petar-qb
• when caching is enabled, remove the original data if the same key exists in lazy data

Test cases:

• test with redis
  to run with redis:

brew install redis
redis-server

then use Vizro._cache_config = {"CACHE_TYPE": "RedisCache", "CACHE_REDIS_URL": "redis://localhost:6379/0", "CACHE_DEFAULT_TIMEOUT": 3000,}

• test with active loading vs. lazy loading

figure=px.box(
                df_gapminder,  # active loading
                x="continent",
                y="lifeExp",
                color="continent",
                title="Distribution per continent",
            ),

figure=px.box(
                "df_gapminder",  # lazy loading
                x="continent",
                y="lifeExp",
                color="continent",
                title="Distribution per continent",
            ),

• test with gunicorn
  to run with gunicorn:

hatch shell
cd vizro/vizro-core/examples/default
gunicorn app:server -b 0.0.0.0:8000 -w 3 --preload

TODOs:

• fix failing unit tests

Screenshot

Checklist

• I have not referenced individuals, products or companies in any commits, directly or indirectly
• I have not added data or restricted code in any commits, directly or indirectly
• I have updated the docstring of any public function/class/model changed
• I have added the PR number to the change description in the changelog fragment, e.g. Enable feature XXX ([#1](https://github.com/mckinsey/vizro/pull/1)) (if applicable)
• I have added tests to cover my changes (if applicable)

Types of changes

• Docs/refactoring (non-breaking change which improves codebase)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Notice

• I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":

  • I submit this contribution under the Apache 2.0 license and represent that I am entitled to do so on behalf of myself, my employer, or relevant third parties, as applicable.
  • I certify that (a) this contribution is my original creation and / or (b) to the extent it is not my original creation, I am authorized to submit this contribution on behalf of the original creator(s) or their licensees.
  • I certify that the use of this contribution as authorized by the Apache 2.0 license does not violate the intellectual property rights of anyone else.

[antonymilne]

Looks really good I think 👍

I've thought some more about exactly what/where the user should set stuff and made some suggestions to swap things round a bit - would be great if you could give it a quick try and hopefully it still works fine. Other than that it would be nice to tidy up the data manager up a bit in preparation to discuss with @petar-qb tomorrow by removing the commented out code 🙂

[antonymilne]

Note to myself to think about whether we want NullCache or SimpleCache as default and whether we want some sort of development vs. production mode that switches cache automatically or gives a hint...

[antonymilne]

Suggested change

	data_manager._cache.init_app(self.dash.server, config=data_manager._cache.config)
	data_manager._cache.init_app(self.dash.server)

I guess that doesn't work?

[lingyielia]

Remove config=data_manager._cache.config from here, as it's duplicate

[antonymilne]

Why do we want this here and called again in the Vizro.build? 🤔

[lingyielia]

Great catch! I now dropped the one in Vizro.build as it's duplicate. We need to put it here so it can prune the original data in two cases:

1. when the dashboard first build
2. when the cache is invalid, and a reload happens

[antonymilne]

Superseded by #398.