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
jonnycharles
I’m in search of an Elixir library that offers PDF generation capabilities similar to Ruby’s Prawn. While there have been discussions abo...
New
spammy
I’m looking to build a personal workflow to quickly deploy web applications written in elixir/phoenix, for local consumption (ie not on t...
New
Blokh
Hey guys, I’ve got a huge CSV ( around 10 GB ) that needs to be processed hourly Do you guys have any suggestions what is the best prac...
New
dli
Before I dive in myself, did anyone successfully sprinkle Hologram into their existing LiveView app? Looking for hints regarding: Addi...
New
roeland
Kia ora, We have been using elixir-google-api to connect to Google Drive. However, with the updates to Tesla due to CVEs this is now bro...
New
bottlenecked
Hi all, I wanted to ask how the community is dealing with post-release steps. Today we have Ecto migrations, which make sure that the db...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
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
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
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