ani
I understand that the a Phoenix controller is the web interface into the bigger application, and the controllers call functions in context. Does this mean that it’s not a best practice to pass the connection struct, which is related to web interface to the contexts?
I have an endpoint that passes through a plug which checks for authentication and assigns an organization, user and token struct to the connection struct. Now, I can explicitly pass all these three values to the context or I can pass the connection struct itself. Which is better?
Thanks
Trending in Questions
Hello!
Suppose you are building workflow (order / task / payment) processing system with the following requirements:
Each workflow con...
New
I’m aware of 2 such projects, are there others?
git: GitHub - team-alembic/realworld: A fullstack Phoenix LiveView application with back...
New
Hi all,
I’m working on a Phoenix project where I need to make external HTTP requests and I’m trying to choose between Req and HTTPoison....
New
Hi everyone.
My team and I have been working on a fairly modest app based around video streaming and chat, but we’ve landed a customer t...
New
Hi,
we run different LLM models across a cluster, with each node loading a configurable subset. Model-specific queues let nodes consume ...
New
Hi all, I’m new here and would like to hear peoples views on my Elixir/Phoenix based game-engine! :smiley:
Mutonex gamedesign was finish...
New
Do we have maintainer of absinthe-graphql/dataloader here? We have a PR that we’d like to merge to the library. Relatively small additive...
New
Other Trending Topics
Hey there,
I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first.
...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex










Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
baldwindavid
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…
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…
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…
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…
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.
kokolegorille
I also avoid passing Web conn to the core.You might want to change for a Text interface later…
LostKobrakai
Plugs and controllers are specifically there to convert the input (being the http request) to input for functions on contexts (now no longer a http construct, but elixir values). Just like a CLI would convert argv input (usually just string values) to elixir values before querying the contexts.
dimitarvp
Really depends what you are after but in any case I am with @baldwindavid that you shouldn’t leak
Plug.Connto your contexts. If you need parts of your assigns / session / private conn attributes then just pass them to your context functions. I’d even advise you to trim absolutely everything from them that you don’t need directly.If you only need
:cart_idand:user_idfor a given context function then I’d do this:As an example pseudo-code.
Absolutely don’t rely on implementation details. Now you have a
Plug.Connbut later you might work with Absinthe (for GraphQL endpoints) and who knows what else.ani
Thank you for the great explanation!