This isn’t a Phoenix question per se, it’s more of a general Elixir how to, but I would like to run some extra code when I first start up my Phoenix application. Specifically, I would like to warm up the cache with entries that are persisted in the database (e.g. session data). There might also be some ad hoc things to do on startup like ping a web URL for notification purposes etc. Where is a valid place to put code like that? Should that all go inside the Application start/2 function?
You can run them in start/2, you can define one-shot Task in default supervisor. In other words - it depends.
For example if this is a cache it doesn’t seem to be highly critical at startup (just if something will require that data before warming up cache it will last a little bit longer) then you can run GenServer/Task that will fill that data and add it to your supervisor before Endpoint, so it is highly probable that it will run before first request came.
I tried adding a child to the supervision tree which boiled down to this:
defmodule MyApp.Application do
alias MyApp.Contexts.MyContext
use Application
def start(_type, _args) do
import Supervisor.Spec, warn: false
children = [
supervisor(MyApp.Repo, []),
worker(Task, [&MyContext.warm_up_cache/0], restart: :temporary)
]
opts = [strategy: :one_for_one, name: MyApp.Supervisor]
Supervisor.start_link(children, opts)
end
end
That works, but blows up with errors when the database is down or being provisioned (which is obvious in retrospect). Instead, I think what I want in this case is a blocking task: i.e. wait to start the rest of the app until this one thing is complete.
Does someone have a good example of how to do something like this? My example here is warming up the cache.
You want the database to be available (I assume Repo) but the app should not be accessible from the outside? Or when you say wait to start the rest of the app, what do you want to prevent happening? Doing a cache warmup seems like something that can run async, unless the cache is the only data source you have.
Maybe if you specify what parts of the app you want to start before your cache warmup and which parts that should wait until after.
eg the Statix library is started by calling connect in start. So with your code example
defmodule MyApp.Application do
alias MyApp.Contexts.MyContext
use Application
def start(_type, _args) do
import Supervisor.Spec, warn: false
:ok = MyStatixModule.connect()
children = [
supervisor(MyApp.Repo, []),
worker(Task, [&MyContext.warm_up_cache/0], restart: :temporary)
]
opts = [strategy: :one_for_one, name: MyApp.Supervisor]
Supervisor.start_link(children, opts)
end
end
That means connect is called before the app starts. But note that in this case, the Repo is not needed for that and not started yet.
In my case, sessions are in the database for analytics and persistence purposes, but from the point of view of the front-end, the only place that gets queried is in cache. It would be possible to have a fallback mechanism that would fall-back to a database lookup on cache miss, but I want to avoid doing that because doing that would open up some vulnerabilities to overloading the database.
Perhaps something like this would have the desired effect:
defmodule MyApp.Application do
alias MyApp.Contexts.MyContext
use Application
def start(_type, _args) do
import Supervisor.Spec, warn: false
:ok = MyContext.warm_up_cache()
children = [
supervisor(MyApp.Repo, []),
]
opts = [strategy: :one_for_one, name: MyApp.Supervisor]
Supervisor.start_link(children, opts)
end
end
