The Webpack Dev Server is purely for development. It is SUPER nice. You never have to reload the page because it just pushes changes to the browser via websockets.
When you push to production you go about things a bit differently. You serve up your index.html file from your server and then pull in the bundled js and css files from a CDN. It makes the site lightning fast.
Guardian allows you to store permissions in the JWT so you can definitely manage permissions that way if you’d like. Channels are super easy to lock down. When you connect to a channel you can pass it params and you could pass it a JWT or other form of authenticating a user. You really don’t need to check permissions for everything client side. It doesn’t matter much if someone gets to a route they aren’t supposed to get to. It only matters if they get to data they aren’t supposed to get to. For that reason it really only matters if you authenticate via http or channels when grabbing data. To authenticate routes you can just check if there is a JWT in local storage, you don’t necessarily need to shoot a message to the server.
The original meteor webpack boilerplate was such a behemoth I couldn’t make heads or tails of it. Then some kind gentleman made a KISS version and I was off to the races. I’d like material to learn from, not a ‘meteor clone’ kitchen sink.
Also, earlier in the thread @SkinnyGeek1010 and I were wondering if JWT is really a good fit for websockets behind TLS. The characteristics of REST that made it useful for clients to assert claims just aren’t there.
Wouldn’t authenticating once then subsequently checking permissions via a bitvector on the server make more sense? One bigint in the user table and you’re good to go. Essentially, guardian without the JWT part.
So, why not use the Phoenix to serve index.html file and add files from cdn? Or is there a better option?
Nice. The reason why I ask are such conditions:
user is on home page, there is a header with login link, check: if user exists (to show login or profile)
user tries to go /profile page, check: if user exists (redirect if not to login)
user tries to go /admin page, check: if user exists; if user has permissions for admin (if not, show 404)
user tries to go /admin/users page, check: if user exists; if user has permission for admin and admin users (if not, show 404)
in admin navigation bar show only links, based on permissions, check: if user exists; if user has permission for admin; if user has permission for each link (show only links, where user has permissions)
So, the component tree was:
App (has user)
AdminLayout (check, if user has admin permission)
AdminUsers (check, if user has admin user permission)
In Meteor, I sent the user data to the client on startup, so I had user with his permission on client every second. With this info I could easily check all above stuff. How would you suggest to do it here?
The phoenix DOES serve the html. The webpack server is like a local CDN, it only serves the bundle.js file for the phoenix html to consume. Phoenix is not aware of what webpack is whatsoever.
2)You really should not be having the admin app with your user app, use seperate app and/or entirely different domain for admin. Then you have none of these issues.
If you really do want to include admin app, then you can redirect on the server side, instead of client side. And since you are using webpack, you can have a normal bundle and admin bundle, and you can serve only the admin bundle if you are authorized
That’s an option, although Sails has some low level realtime support. The main issue with holding open lots of stateful connections is that Node is not great at doing that. Elixir/Erlang was designed for that specific use case and it excels at it.
Why do you argue with me? Phoenix in the above example does not serve the html, it is only used as an api server. You can check the repo and see it yourself.
In Meteor you ship all templates together to client. With webpack we can ship bundles or chunks, I am trying now to decouple the app. Maybe you have a link with this idea?
Sorry, i apologize i didnt actually see he was serving the html thru webpack, i dont think it should be done that way.
for 2) i thought you would be using react with webpack not blaze. And honestly, if i were you, for now i would just make the admin url obsure before i refactor. You are worrying too much about the user experience for people who are not suppose to visit a route they are not told to visit, as long as the data are not sent down the wire before authenticating you are fine.
Would you recommend using Phoenix instead of Meteor? We really dont like Meteor’s inability to choose and stick to a course. (Flow/Iron, React/Blaze, Coffee/js…,…) We need a tool that big corps can rely on.
Sure. I definitely think Phoenix is ready from prime time. A number of companies have moved off Rails and on to Phoenix as their real-time needs have grown. I love Phoenix. If you guys like it too then go right ahead!
When an event is broadcasted with broadcast/3, each channel subscriber can choose to intercept the event and have their handle_out/3 callback triggered. This allows the event’s payload to be customized on a socket by socket basis to append extra information, or conditionally filter the message from being delivered. If the event is not intercepted with Phoenix.Channel.intercept/1, then the message is pushed directly to the client:
How do you manage to do some things in Elixir/Phoenix that were really accessible and easier with NPM/Atmosphere packages.
For example, a lot of libraries/sdk are only available for JS, Python, Ruby, Java. How do you manage that ?
Another example, when an API sdk is not available for elixir, do you manually do all the HTTP calls and construct the URLs as strings by yourself ? ( Since I discovered Node, I became very lazy )
)