History of PhoenixSlack20151101

HomePage | RecentChanges | Preferences

Revision 8 . . December 22, 2019 9:52 am by 78-93-98-198.dsl.wavetel.us
Revision 7 . . November 1, 2015 5:27 am by

Difference (from prior major revision) (no other diffs)

Changed: 1,105c1

Phoenix Slack Channel 2015-11-01

Note: Some conversations have been grouped. Lines may be out of chronological order.

aarond [11:57 PM]
Would it be a bad idea to load a `current_whatever` in a plug at the router scope because itís needed in the layout?

aarond [12:00 AM]
Or guess what Iím really asking is where should the code go the load data used in the layout, it feels messy having to do it in several controllers

gjaldon [2:17 AM]
@aarond I typically add a `current_user` field to `conn.private` when a user has already signed in. Then I have a helper function that I import in my views and controllers called `current_user(conn)` which just does `conn.private[:current_user]`. If youíre doing something in multiple controllers, extract the function to a module that you import in all your controllers. For example, create a `ControllerHelpers?` module and them `import` it in your `controller` function in web.ex

lostcross [12:28 AM]
joined #phoenix

lostcross [12:36 AM]
When I try to use `as: :v1` in a scope in my router file, I get an error "function post_path/3 undefined" despite the fact that I'm pretty much copying the docs

lostcross [12:39 AM]
Pastebin of my router.ex file: http://pastebin.com/4k4rSvtm
defmodule ApiTest?.Router do use ApiTest?.Web, :router pipeline :api do - Pastebin.com (8KB)

lostcross [12:40 AM]
I assume I'm doing something wrong, because I doubt the docs are wrong, but I can't find the problem...

fernandobaroni [12:40 AM]
joined #phoenix

utkarshkukreti [12:42 AM]
@lostcross: what does `mix phoenix.routes` say the name of the route is?

mamun [12:42 AM]
joined #phoenix

trenpixster [1:28 AM]
Hey @bklang! Thanks, itís a joy knowing itís being useful! Giving back rocks :simple_smile:

weixiyen [1:42 AM]
I have a question around phoenix production best practices. In a multi-datacenter production environment, it seems that the default setup is that all the phoenix nodes would all know about each other, and the channel websocket / long-polling connections would live on the same nodes as the app servers serving regular HTTP requests. My question is shouldnít channels be separated out onto their own nodes separate from the app server machines? What are phoenix best-practice recommendations in distributed production environments? (edited)

gjaldon [3:00 AM]
@weixiyen: I think having all nodes able to handle websocket connections would better balance out load. if you have 1 node that handles all websocket connections, wouldnít it be much faster to use up its resources since websockets are persistent connections? if you want to separate out websockets to a single node and all other nodes just handle regular http, you could have a Phoenix app that only serves websockets (remove all other plugs that except for the websocket plug in MyApp?.Endpoint). For the regular http servers, remove the websocket plug so they only serve http. Then have a proxy server in front

weixiyen [3:18 AM]
Ah, yes, I suppose that solves my case by just proxying up front, was just wondering if thatís what everyone else was doing. Thanks again. The reason I asked was simply if every single node could handle websocket + http requests, then each node has less capacity for the websocket stuff, which means youíll need more servers that must know about each other for the same capacity, potentially increasing network traffic in a pubsub model. Is the pubsub smart enough to know exactly which other nodes to send to? (say server B does not have anyone subscribed to the ďphoenixĒ channel), would it know not to publish to Server B?

weixiyen [3:34 AM]
also do i really have to remove the plugs if iím proxying? is there a performance impact of leaving them in?

gjaldon [5:49 AM]
@weixiyen: you donít have to remove the plugs. thereís probably a performance impact, but likely negligible. I havenít really measured. Iíd prefer to remove them though since they arenít used in the pipeline. it makes the code clearer (edited)

weixiyen [6:04 AM]
got it thanks, yeah I was just thinking it may be easier to deploy and manage if everything was the same codebase

sysashi [1:55 AM]
joined #phoenix

underplank [5:53 PM]
How and where does Phoenix open and close database transactions and or connections?

gjaldon [7:21 PM]
@underplank: youíll have to look into Ecto. Ecto starts a pool of connections it keeps open as long as the application is running

underplank [8:31 PM]
@gjaldon: OK, so by default phoenix does nothing about opening or closing transactions. How are most people dealing with transactions in Phoenix. In OOP languages Iíve had a BaseResource? that handles the opening/commiting/rollback on error logic. That doesnts seem like the right approach here.

gjaldon [2:21 AM]
@underplank: youíll have to look into Ecto for that because Phoenix does not deal with the database. If you want transactions, check this out http://hexdocs.pm/ecto/Ecto.Repo.html#c:transaction/2

efu [2:38 AM]
@gjaldon you can use conn.assigns too. I have read that the conn.private is reserved for frameworks

gjaldon [2:45 AM]
@efu itís a matter of preference. I used to put it in `conn.assigns` too but then accessing it in templates and controllers would be different. in templates, you do `@current_user`. in controllers, youíll have to create a function like `current_user(conn)`. when used in `conn.private`, you use the same function in controllers and templates.

itís a convention that private in conn is there to be used by frameworks/libraries, but isnít a strict convention and users are free to use it as long as there arenít any conflicts with fields of libraries you use which are usually properly namespaced. in fact, it was jose valim that initially suggested to use it to store `current_user`.

efu [2:46 AM]

lispberry [3:38 AM]
joined #phoenix

zlajo [5:34 AM]
@wsmoak: Thanks! I was able solve my problem. I still have to get used to all the immutability stuff. :simple_smile:

HomePage | RecentChanges | Preferences