fireproofsocks

fireproofsocks

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?

Thanks for any tips!

Showing Posts 1 to 6

hauleth

hauleth

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.

fireproofsocks

fireproofsocks OP

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.

Thanks for any guidance!

jola

jola

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.

fireproofsocks

fireproofsocks OP

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
sdr

sdr

Application.start_phase looks like another option.

Docs are a little light but the Erlang docs go into greater detail.

— All posts loaded —

Where Next? Top

Trending in Questions Top

stjefim
Hello! Suppose you are building workflow (order / task / payment) processing system with the following requirements: Each workflow con...
New
water
I’m aware of 2 such projects, are there others? git: GitHub - team-alembic/realworld: A fullstack Phoenix LiveView application with back...
New
itzmidinesh
Hi all, I’m working on a Phoenix project where I need to make external HTTP requests and I’m trying to choose between Req and HTTPoison....
New
peck
Hi everyone. My team and I have been working on a fairly modest app based around video streaming and chat, but we’ve landed a customer t...
New
leoschweizer
Hi, we run different LLM models across a cluster, with each node loading a configurable subset. Model-specific queues let nodes consume ...
New
csmr
Hi all, I’m new here and would like to hear peoples views on my Elixir/Phoenix based game-engine! :smiley: Mutonex gamedesign was finish...
New
Stef-Verniers
Hello I’ve been coding in Elixir for almost two years now because of my current job where we implemented Elixir in our application. But ...
New

Other Trending Topics Top

dominicletz
Hey there, I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first. ...
New
mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
OndrejValenta
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly) AI dream has many faces, but general...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews