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
katta
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
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
bradley
I really like the adapter patterns that ecto, nebulex, waffle, etc. use and would love find something similar for a key management servic...
New
unaware8150
Hello folks! So at work, we are seeing some situations where we have to define some “fixed” strings that are used across the codebase in...
New
Alvinkariuki
How Can I Optimise Compile Time Dependencies I have been building an elixir application for about 2 years now. Many modules and files ha...
New

Other Trending Topics Top

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
juhalehtonen
There has been a thread to discuss the Stack Overflow Developer Survey on this forum every year since 2018, so here’s yet another one for...
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New
ausimian
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews