HN Theater @HNTheaterMonth

⬐ digitalzombie

The search bar doesn't work over at phoenixframework.org (using firefox).

I was trying to search for API authentication.

How easy is it? And what protocol do phoenix have in place for authentication? Thanks.

Are you planning to have a vagrant box for Pheonix?

Laravel have this, named Homestead. I thought it was pretty easy and awesome.

⬐ oomkiller

There is work going on right now to help add support for API token auth, you can follow it here: https://github.com/phoenixframework/phoenix/pull/820

⬐ doomspork

Not OP but I've been playing with both Elixir and Phoenix recently and I must say it's been pleasant. With experience in Ruby (and Rails) and an understanding of FP I was able to dive right in.

⬐ bphogan

Hi. There's nothing out of the box for API authentication. But I set up authentication in less than an hour for my app yesterday. You really want to learn how Plug works, and doing that opens up so many possibilities. I'm frustrated that there are so many things missing right now, because I'm used to Rails where everything exists right now. But I'm finding that having to do these things myself helps me really learn how Elixir works and it's opening up a lot of possibilities.

⬐ doomspork

For me the lack of available solutions is an opportunity to contribute back, something that I find can be more difficult with established projects.

⬐ UserRights

How can I do object level permissions with Phoenix and ecto?

I can not find anything about advanced security features in the docs (not only because the search on the site is broken).

⬐ chrismccord

Creator here. I'm happy to answer any questions. We had our first ElixirConf in Europe a couple weeks ago and I showed off our new features and what it's store for 1.0 in July. For those that want to take Phoenix for a spin, we've have getting started guides to get up and running quickly:

http://www.phoenixframework.org

⬐ ffn

Great talk OP, phoenix will probably become my go to alternative to my current hybrid rails+nodejs stack as I learn more about Elixir. But because Elixir (and Phoenix) is still rapidly changing, I find tons of stuff I've written even several months ago just sort of stops working if I don't upkeep it frequently. This is just the nature of using new things, but do you have a recommend elixir version manager you use?

⬐ chrismccord

I just build from source as needed, and I find it refreshingly simple. This will probably break down on future Elixir versions, but for now it's my preferred approach. There are libs for switching elixir/erl versions, fwiw.

wrt fast changeds, Elixir has been 1.0 stable for 7 months, and Phoenix is targeting a July 1.0 release. We are quite close to 1.0 as it is, so things should be much smoother now if you checked us out several months ago.

⬐ MCRed

Congrats on the popularity of Phoenix. The documentation is quite excellent!

I'd be interested in your perspective on the current state of the elixir web framework scene and where you think it's going.

Specifically, how would you compare Phoenix and N2O?

Would you say the perception is correct that Phoenix is going very much into the direction of Ruby on Rails? (Generators, you and Jose are rails contributors, etc.)

I'm torn. On one hand Phoenix has the momentum, but on the other, I feel like it's making a lot of assumptions that don't hold in my situation. (EG: I'm doing routing at runtime because the routes change, I don't store anything on the local drive, so no static data there, I'm doing an unusual way of composition to produce what's sent to the browser. I haven't run into any blockers to using phoenix just feel like I'm fighting it sometimes.)

Yeah, sorry, vague question. :-)

⬐ chrismccord

Thanks!

> I'd be interested in your perspective on the current state of the elixir web framework scene and where you think it's going.

One of my goals from the start was to rally around Plug (https://github.com/elixir-lang/plug), which is our webserver abstraction and middleware lib (somewhat like Rack from Ruby, or Ring from Clojure). With Phoenix, Plug is core to the framework and we don't hide it like Rails does with Rack. So in Phoenix, Endpoints, Routers, and Controllers are Just Plugs. This makes things less magical, simplifies the request lifecycle, but most importantly it allows easy interop with community libraries. So plugs released for framework X, phoenix, or "pure plug" usecases will just work across all codebases. So the for "elixir web framework scene" I see a vibrant community around not only Phoenix, but Plug in general and other libs built on top of it.

> Specifically, how would you compare Phoenix and N2O

I have no direct experience with n20, but some of our realtime goals overlap and they have done really great work. We use their filesystem watching lib for our live-reload feature. We don't go to the level of writing html abstractions not the server to push updates over, but it's a really neat idea that I would like to explore doing over Phoenix channels after 1.0 is out. If you see my work on Sync, a gem for realtime rails partials, I explored things around these ideas.

> Would you say the perception is correct that Phoenix is going very much into the direction of Ruby on Rails? (Generators, you and Jose are rails contributors, etc.)

To be clear, I'm not a Rails contributor, but I have done Ruby/Rails professionally for 6 years or so. It depends what you mean by "direction". Rails set the bar for productivity and onboarding out of the box, so we aim to go this direction in spririt, but we aren't out to match feature to feature. We are also taking a more explicit approach (thanks to FP). I would say our goals for bootstrapping productive apps quickly with fast iteration is where we match Rails, but we are ready to take on the world out of the gate perf wise. Phoenix is also deviating on a the traditional "web framework" notion. Browsers aren't going anywhere, but we should have a framework that can hold persistent connection and broker messages across connected devices; many coming over browsers, but iOS, Andoid, et al as well. That's where the world is heading and where Phoenix aims to excel. So we should be great at the standard server rendered html, form builders, etc, but we're trying to take it to the next level with channels.

> ... I haven't run into any blockers to using phoenix just feel like I'm fighting it sometimes.)

I can't help if we don't have specific code examples. I always tell people we aim for the common 80% usecase that we all share. Special use-cases will always require deviations from any framework. Since our http stack is "just plugs" you should be able to easily get the best of both worlds with your needs while still using phoenix. Find me on IRC with some gists and we can see about making it work well :)

⬐ MCRed

Thanks for the response! I read it yesterday and thought about it and did some investigation and just read it again today. You've convinced me to go with Phoenix for a couple weeks and see how that goes. I think what sold me was you selling me on plug, as I think that is the correct solution and answers the core issue (that I was having trouble articulating.)

I am definitely not working on the %80 use case you're targeting, in fact, the best explanation of what I'm doing is I'm competing with you. I agree with you on the choice of elixir, and I agree with you about the direction of connected devices but we have some philosophical differences in solution. (One could say you're coming from the web world, and I am coming from the native world.)

But I will work on breaking out my solutions, as much as possible, into plugs so that people using phoenix can use them.... and if I end up pulling in some N2O I'll probably wrap it as a plug.

And since phoenix is based on plugs and lets you build a pipeline, this may be pretty convenient.

Thanks again for your work, contributions to making Elixir the Next Big Thing and your answers above!