I would like to request Phoenix.Endpoint.init/2 callback not be deprecated

[nshafer]

Environment

• Phoenix version (mix deps): 1.7.11

Actual behavior

The Phoenix.Endpoint.init/2 callback was deprecated in 1.7.11. It prints the warning "MyappWeb.Endpoint.init/2 is deprecated, use config/runtime.exs instead or pass additional options when starting the endpoint in your supervision tree" however neither of those options work in the same way that the original init/2 callback did. It's mostly due to timing:

• "config/runtime.exs" is executed at VM startup, before any application code is run
• Additional options passed to the Supervisor in "lib/application.ex" are evaluated before the supervision tree starts up.
• The MyappWeb.Endpoint.init/2 callback is/was executed at the time of the Endpoint starting up, particularly after all previous children have already been started.

The main reason I'm having a problem with this is that I need to configure the Endpoint based on configuration that is pulled from the database. I have been happily doing it in the init/2 callback since the Myapp.Repo was already started and available. The two offered solutions do not allow any configuration from the database that I can figure out.

I have figured out a workaround, but it is rather ugly, and assumes things about the internals of Phoenix, specifically Phoenix.Endpoint.Supervisor.start_link/3. It works by creating my own start_link/1 function that gets the dynamic configuration then calling Phoenix.Endpoint.Supervisor.start_link/3 with that dynamic configuration. However, I'm pretty sure this is crossing the private boundary of the Phoenix internals, and could break with a future update.

More information with an example and workaround code:

https://blog.lotech.org/dynamic-configuration-for-phoenix-endpoints.html

Expected behavior

Since the init/2 callback offers an elegant solution to this particular problem, and the given alternatives are not a functional replacement, I'd like to request that init/2 is not deprecated.

I can also imagine other people having similar issues if they depend on some other part of their supervision tree being available during endpoint dynamic configuration.

Thanks!

[josevalim]

You can do this:

%{id: MyApp.Endpoint, start: {MyApp.Endpoint, :custom_start_link, []}}

And from there you read from the database and call MyApp.Endpoint.start_link/1. :)

[nshafer]

OK, no problem. I updated my blog article with a similar solution for anyone else that runs across this. I still keeps things in a separate file, but I call the macro-generated MyappWeb.Endpoint.start_link/1 as well, so it doesn't reach into the internals. Thanks for the consideration.