Don't inject PHX_SERVER by default

[nickdichev-firework]

Hi, just poking around the code and I thought it was strange that by default the children have PHX_SERVER injected.I have a use case where I need the children to be running the phoenix server.

My understanding is the caller can decide if they want to start the Phoenix endpoint in their supervision tree (via FLAME.Parent.get()), so I don't understand why this environment variable must be injected and not be overridable. It gives the caller more flexibility to let them figure out if the endpoint should even be started and how they want to configure the server.

[mruoss]

Honestly, I have copied this code from the FLAME.FlyBackend without giving it much thought. Maybe @chrismccord could enlighten us on why this ENV is set to false on the FlyBackend?

[josevalim]

It probably makes sense to disable it by default but I agree it should be overridable. Especially because the endpoint may start other "services". @nickdichev-firework, what in particular do you need from the endpoint?

[mruoss]

Thanks @josevalim for jumping in. Maybe we can just remove the ENV var from the Enum.reject() (as you did in this PR) but leave it set to false by default (undo that change)? This would make it overridable.

[nickdichev-firework]

@mruoss Great, I will make those changes today.

@josevalim I have a service which implements a FLAME-like runtime without requiring the parents/children to be clustered. The children serve a phoenix API for clients running in our kubernetes cluster to interact with a membrane pipeline. We explicitly chose to have the clients talk HTTP/websocket directly to the children.

We are evaluating FLAME to replace our in house solution, its interesting to think about proxying these calls through the parent in the context of the FLAME cluster :)

[chrismccord]

Seems like I added this early on, but the release of the container will still exec the server overlay, which sets PHX_SERVER=true, so I don't think this default does even what it was aiming to do, and I can confirm the correct way to prevent the endpoint from starting would be to handle it in your sup tree, so ship it!