There’s Phoenix.Endpoint.init/1, which is called when your endpoint starts up. Not per controller, but still.
Controllers in phoenix also implement a interface (even if not explicitly via a elixir behaviour). They’re plugs. MyController.call(conn, action) and you don’t need to start any infrastructure around it.
Yes but testing them without the endpoint and router is a real pain. First it’s going to complain about the session, then the flash, then something else, bwah.
I agree with this sooo much. I think the problem lies exactly in the fact that we can’t inject state into the Plug connections from the regular supervision structure - for any other processes we have start_link and the init callback or other mechanisms, where we can set-up the state for the process - including dependencies, but we entirely lack that possibility with plug. For some reason Plug tries to enforce completely stateless processes.
I somehow forgot Phoenix.Endpoint.init/1 was only for configuration, but can’t a plug at the start of the endpoint do something similar.
defmodule MyApp.Application do
def start(_, _) do
children = [
{MyApp.AceController, config()}
]
…
end
def config() do
…
end
end
vs.
defmodule MyApp.Application do
def start(_, _) do
children = [
MyApp.Endpoint
]
…
end
def config() do
…
end
end
defmodule MyApp.Endpoint do
plug :prime_with_config
def prime_with_config(conn, _),
do: put_in(conn.private.my_app_config, MyApp.Application.config())
end
In both options the context of execution does get the config. I’m sure the first option would be cleaner, though.
It basically takes a conn, applies all the plugs of the endpoint and any router pipes if any and returns the updated conn. Which should solve the issue of sessions not being available and such.
I am not going to discuss the overall architecture ideas here but I would like to talk about the “Modules don’t compose well” bit, in particular this one:
Modules in Elixir provide the same expressive power as functions. From the perspective of functional programming, they are the same, modeled by the same principles, and the same power for composition. Maybe one is more verbose than the other, and that may be what “compose well” means in this context, but they are not different in the ability to compose.
If you have two functions, how can you compose them? We can write the compose function like this:
defmodule Foo do
def add_2(x), do: x + 2
def mult_2(x), do: x * 2
def compose(fun1, fun2), do: fn x -> fun2.(fun1.(x)) end
end
And now:
iex> Foo.compose(&Foo.add_2/1, &Foo.mult_2/1).(13)
30
How can we compose modules? In similar way. Let’s assume each module has a contract, it has to implement call:
defmodule Add2 do
def call(x), do: x + 2
end
defmodule Mult2 do
def call(x), do: x * 2
end
defmodule Compose do
def compose(mod1, mod2) do
name = Module.concat(mod1, mod2)
defmodule name do
@mod1 mod1
@mod2 mod2
def call(x) do
@mod2.call(@mod1.call(x))
end
end
name
end
end
And now:
iex> Compose.compose(Add2, Mult2).call(13)
30
The difference between the approaches is in their cost: defining the modules are much more expensive. But this is a runtime property. Plus, it can also be made cheaper by having each “module call” be represented by a tuple {Mod, arg}, and then you can compose without defining modules dynamically. Namely, the benefit of functions is that you can close over the current environment (closure) and by using a tuple you can emulate the same with modules.
in fact, one can say the advantage of a module is that you can define multiple functions and compose over multiple functions at once, but this is also possible with anonymous functions. You just need to add a new argument to the function signifying the operation you want to do. From a functional programming perspective, there isn’t much difference between those two:
defmodule Calculator do
def add(a, b), do: a + b
def mult(a, b), do: a * b
end
calculator = fn
:add, a, b -> a + b
:mult, a, b -> a * b
end
Protocols also provide the same sort of composition as anonymous functions, with the benefit they are open and can be defined/implemented at any time. In fact, a protocol may be a nice solution for your problem.
Anyway, the reason why I am saying this is not to say “you are wrong”, but maybe it can help you put a finger on what you don’t like about the current code.
I am not sure I follow the point here. Plug pipelines can be defined completely dynamically. For example:
[
{Plug1, opts},
{Plug2, opts},
{Plug3, opts},
]
And then to execute it:
plugs
|> Enum.reduce_while(conn, fn {plug, init}, conn ->
case plug.call(conn, plug.init(init)) do
%{halted: true} = conn -> {:halt, conn}
%{} = conn -> {:cont, conn}
end
end
|> elem(1)
This can also be meta-programmed and compiled into a module when the app starts for performance. But in a nutshell, you can always move the Plug to the runtime. However, I would avoid doing this, because understanding what my pipeline is actually doing becomes much harder. I would indeed prefer to keep them static and read the state from elsewhere.
And this is somewhat my concerns with the proposed code in the thread: the code may be less coupled but we lose a lot in clarity. This could be beneficial if the controller ultimately become a dumb layer (imagine that multiple gateways and business rules are served by the same controller) but I personally wouldn’t do it for individual cases.
This is not something Ace solves either because if you want to make decisions based on the user, which you would most likely do, by the time you know exactly which user you have, you are already too deep into the request life-cycle (and therefore inside both Ace and Plug requests). Futhermore, both Ace and Plug are module based contracts and both allow you pass arguments when building the supervision tree.
I don’t mean plugs at all in here. I’m talking about processes - the process that is started for the request happens somewhere completely in the internals of the library and you have no access to that. The regular way of setting up state for services through start_link and init is not available.
What I’d like to see would be to have something like:
# in application.ex
children = [..., {MyApp.Endpoint, some_initial_options}, ...]
# in MyApp.Endpoint
def init_conn(conn, those_options) do
# set up initial state for the Conn struct that is later used by this request
# basically - the same as init for a gen_server
end
This would allow handling plug request processes as any other processes in the system - right now they are somewhat special and separated from the supervision tree in that there’s no way to pass state into them. The whole state has to be either provided statically (in some module somewhere) or through mutable memory (an ets table or application env).
Sorry, but I am still not seeing how that is different to this:
children = [
{Plug.Cowboy, scheme: :http, plug: MyRouter, plug_opts: some_initial_options, options: [port: 4001])
]
While init is called at compile-time, call will be invoked with the custom options. But if you ignore the names and think they are init_compile and init_runtime, the result is the same (basically, for a process that runs sequentially, like a task, there is no difference between a init+run and just having init or just run).
Maybe the complaint is that Phoenix.Endpoint does not allow you do the same (which can be fixed in like 10LOC) but again, I am not sure which problem it solves. You have to build the supervision tree inside the Application callback. And how do you pass information to the application callback? Usually with the application environment. Then we are back to square one.