I would love to hear other opinions on this, but I think the key thing here would be that the contexts do not specifically know about %Plug.Conn.

You definitely don’t want this context function signature…

def create(%Plug.Conn{} = conn)

You could be less specific about it and grab things out of a struct that just happens to have the same structure as a conn if it really makes sense for your context API, but it almost surely does not…

def create(%{assigns: %{organization: organization, user: user, token: token}})

However, this is coupled to the structure of a conn and doesn’t seem like clean arguments for the context function.

You could pass just the assigns so as not to reach deeply into the struct…

def create(%{organization: organization, user: user, token: token})

But you are still reliant on how the conn is built up on the web side of your app and it is still arguable whether this is a clean way to take arguments in the context function.

Try to imagine you didn’t have a web interface for your app at all and were only designing the context function. How would you want the function signature to operate? Let that dictate what/how arguments are passed in.

For instance, maybe a function signature like this makes more sense in your app…

def create(%Organization{} = organization, %User{} = user, token})

This should be more resistant to breakage due to changes in the controller because you will have been explicit of the needs of the function at the boundaries.