This PR moves the caching logic into logically independent modules, and define supervision tree to start the caches and do initialisation at the same time.
The main benefit is defining a cache and warming it up is now in one place instead of spread across the application.ex and startup.ex files.
One thing to note: some caches are used together. For example config_site_type_store and :config_site_cache are both used by add_site_config_type. In this case, the restart strategy should be :one_for_all so that if a cache dies, the other is also terminated, and then both are restarted before initialisation.
This should be reviewed commit by commit where I tried to only move small bits at a time.
Ultimately I want to straighten up the startup logic which has a bunch of init code outside supervision trees, but that'll come later.
How to test that?
There shouldn't be any functional changes, so:
starting up
login as admin and doing a quick permission check (can you access protected parts?)
start up a lobby and issue a command like $help or $whois
This PR moves the caching logic into logically independent modules, and define supervision tree to start the caches and do initialisation at the same time.
The main benefit is defining a cache and warming it up is now in one place instead of spread across the application.ex and startup.ex files.
One thing to note: some caches are used together. For example
config_site_type_store
and:config_site_cache
are both used by add_site_config_type. In this case, the restart strategy should be:one_for_all
so that if a cache dies, the other is also terminated, and then both are restarted before initialisation.This should be reviewed commit by commit where I tried to only move small bits at a time.
Ultimately I want to straighten up the startup logic which has a bunch of init code outside supervision trees, but that'll come later.
How to test that?
There shouldn't be any functional changes, so:
$help
or$whois