I quite prefer this explicit form actually, plus I can control when I actually need to do it so I don’t necessarily always incur the cost like with plug. 
OvermindDL1
0
Qqwy
TypeCheck Core Team
I should have explained my previous question a bit more thorougly:
Because you have to provide statements that call the internal functionality of the middleware explicitly, what happens when I want to write a middleware ‘A’ that itself internally depends on another middleware ‘B’ to function? Does the user that wants to use ‘A’ also need to write the explicit statements to make sure ‘B’ works, is calling ‘A’ enough and can it dispatch to ‘B’ internally on its own?
Maybe it’s still a bit vague, and maybe I am also describing a scenario that is more complex than the scenarios you currently are exploring.
1
josevalim
Creator of Elixir
With Plug you have full control too. fetch_session and plugs are regular functions, just call it when you want to, you don’t need to have it as part of a pipeline.
2
OvermindDL1
Yep I know, I do that at times too, properly baking the init at compiletime and all.
However I tend to thread my conn all over the place and different parts need different bits, sometime at the same time, but I cannot be sure that it’s already acquired or not so I test in some (otherwise expensive) cases. This is why it would be nice if all the getter functions returned a Tuple of both the value and the conn, that way it caches it on the conn if not there and I can thread it with impunity without worrying about writing my own tests for if it is already cached or not. Returning just the value means I have to remember to do things like fetch_session manually at the right times. (Basically I think conn should be a state monad threaded through all of its calls, every single call regardless of if used or not.)
0
OvermindDL1
Hmm, an idea, conn could have a value key on it a which is the return of the most recent getter otherwise ignored, then every function would just take and return conns and it could be piped with impunity (especially if about to name returns via another call, everything could become such a nicer pipe). 
0
josevalim
Creator of Elixir
Cowboy did that on v1 and basically reverted back because it pushed the complexity to most applications while they absolutely do not care about this.
In any case, you can implement such function easily using the fetch_session (which is a no-op if the session is already fetched) and get_session:
def fetch_session_key(conn, key) do
conn = fetch_session(conn)
{get_session(conn, key), conn}
end
1
OvermindDL1
That one is a noop yes, but not all were, I ran into some expensive ones that weren’t, like grabbing the body I think was one? In addition to other libraries.
And I can see the complexity with the Tuple, a couple extra things to type, but putting a value return on the struct itself makes it far easier, hence why suggested.
0
Crowdhailer
Creator of Raxx
This is certainly true, once there is an assumption of middleware there will be libraries that are written that assume some functionality is only useful as middleware and bake in that assumption.
It’s certainly interesting to explore the alternatives. @OvermindDL1 I would love to see anything you have that would fit into the topic of “You might not need that middleware” I hope to write something about that eventually but don’t see it happening soon
0
josevalim
Creator of Elixir
Afaik, the only thing we don’t store is the body, because storing the body has large implications.
Exactly. 
Which is one of the reasons why we decided to avoid the notion of middleware in plug altogether.
2
OvermindDL1
Honestly I’ve never really used middleware, I’ve always preferred explicit calls, even when I’ve made web servers in C++, though I may be a bit of an odd-ball out. ^.^
0