Permanent == started on app startup and staying there until the app shuts down.
Thanks to this distinction, DynamicSupervisor allows you to start and stop children processes at any time. You also are not strictly mandated to stop them; they will be stopped when the supervisor itself is stopped (although it’s definitely a good idea to stop children proactively after they’ve done their job IMO).
To me, using DynamicSupervisor is appropriate in two scenarios:
- When you would like to spawn quite a lot of (say, at least 200,000+) processes because I’d wager then a performance (or memory) impact would start becoming noticeable.
- When you need to create processes in response to – or because of the specifics of – external systems whose resources you have to monitor e.g. a web crawling service to which you give a new domain to crawl. It would need to spawn processes to enumerate URLs and then maintain a small pool of workers to do the crawling (and apply rate limits if applicable).
I’d say especially the latter option is pretty valid; there are many real-world examples where you cannot neatly plan a supervision from the start because things do change at runtime. DynamicSupervisor is ideal for this.
