When is it a good idea to reach for my own supervisor tree inside of a Phoenix application?

I’ve been writing a few applications at work in elixir/phoenix and I understand that Phoenix and Ecto utilize supervisors and processes under the hood but I’m curious as to when it’s a good idea to reach for my own supervisor tree inside of a phoenix application? My only idea would be when I need to reach for some background job processing that it would make sense to do that.

Are there any other common problems inside of a phoenix / web app that a supervisor tree and/or OTP Genservers make sense?

1 Like

Yes, embrace supervision trees for any additional processes beyond the Cowboy handler and Ecto pools. Some use cases I’ve had for starting additional processes:

  • caching data in ETS owned by a GenServer
  • Task.Supervisor for non-durable async tasks
  • GenStage producers / consumers for interacting with external systems
  • Postgrex.Notifications

Only thing to watch out for is introducing bottlenecks by putting stateless business logic behind GenServer interfaces.

3 Likes

@sasajuric has a great article , that can help you

To spawn, or not to spawn?

4 Likes

Your own (application and) supervision tree becomes important once you decide to build the application independent of Phoenix - i.e. Phoenix is simply used to build the web interface for your application - an approach advocated in

Discussion: Don’t add a database layer to your Phoenix application

(example)

and demonstrated in

Functional Web Development with Elixir, OTP, and Phoenix (Pragprog).

See also: What do they actually mean when they say "Phoenix is not your application"?

2 Likes

This talk by Fred Hebert has some inspirational chunks about supervision tree design.

2 Likes

I use separate processes, for background processing, plus a common ephemeral store for data that gets used in multiple requests (because the data can be reconstituted by hitting an API, but I don’t want to hit that API on every request).