I started with Elixir last year, after ten years of Erlang - definitely an upgrade!

My favorite improvement is the existence of Ecto - what an amazing piece of software.

Thanks for all your work and vision!

I've also realized in this past year that the first thing I miss when going back to Node or another stack is Ecto.

That doesn't diminish anything about the Elixir language, either. In many languages, Ecto's DSL wouldn't be performant, practical or even possible.

Thank you very much fir creating Elixir! It’s an absolute joy to program in and it’s something I foresee using for a very long time.

Thank you for your work on adding user registration and authorization to Phoenix!

I'm setting up a new Phoenix app for a side project this weekend and have just run Arron Renner's auth generator[1]. Having user registration out of the box will save a big chunk of time and energy!

1: https://github.com/aaronrenner/phx_gen_auth

Congratulations on the anniversary and thank you for all of your efforts and contributions, Jose.

Thanks for creating Elixir. Before using it and going through the website and docs I thought it would be good but once I started to use it, I discovered it is excellent.

I'm going to shamelessly take advantage of your being here with a question if that's ok. Do you have any recommendations for reading material that covers Phoenix as it's used today?

Back in the early 0.x days I read the Phoenix book, which was a great introduction to building an application and using Ecto, but trying to pick it up again recently I found that nothing really seems to cover using Contexts in the real world.

You probably have seen it already, but recent Phoenix docs have a section on contexts and what is their intended use case: https://hexdocs.pm/phoenix/contexts.html

The way I see it, context are just the public API to access your data model. Your Ecto schema is a piece of data, which in a functional language has no behaviour attached. The (business) logic to deal with this piece of data lives in the context. That's it.

It's nothing particular and specific about Ecto or Phoenix, it's just a good design practice that's applicable and recommended in any language.

Gary Bernhardt at https://www.destroyallsoftware.com has a few screencasts and talks about this very topic.

Thanks, I'm not GP but have the same questions.

What about access control? That's often directly tied into business logic, but it's so elegant and convenient to do it in the controllers or even the router using the pipelines. In fact a ton of the examples (I think even the Chris McCord Phoenix book) does exactly this, presumably for that reason.

However I did that with an app and haven't been very happy with it because while the bulk can easily be done in the router/controllers, there are things that are totally inappropriate to do there and so it ends up in the context. Then your logic is distributed and messy, which is awful. But putting all access control in the context also bloats and complicates a ton of otherwise very clean, elegant API functions. I try to keep the Repo query building code clean and separate but that often leads to inefficiencies (such as filtering fields in the caller instead of in the generated SQL, which is vastly preferred for obvious reasons).

Anyway, interested in thoughts on that.

Personally, here is what I do: if access control is part of the business model, then I put it in the context and, almost always, I raise. Otherwise, continue doing it in plugs. That's it!

For web apps, you should almost never be triggering these invalid access control state, because it means the UI is allowing users to do something they are not really supposed to do. If the user cannot delete a resource, then the button most likely shouldn't show up (or it should be disabled with a comment) etc.

Raising actually helps us find these bad UI paths too because I get an error I can act on.

Now let's say you do want to handle some of these errors. You have three options:

1. Continue raising and rescue in the controller (meh)

2. Continue raising and implement Plug.Exception for said exception so you control how they are shown to the user (great if they are still general exceptions)

3. Return {:ok, _} | {:error, ...} and handle it in the controller (or in the FallbackController for APIs)

That is incredibly helpful. Thank you!

There’s already an article on this you can find here: https://dashbit.co/blog/a-new-authentication-solution-for-ph...

The GitHub for the generator is here: https://github.com/aaronrenner/phx_gen_auth

Basically if you need something different it might be worth forking the generator. I might look at passwordless login at some point.

That's phenomenal, thank you! I added the link to my "to do" list and realized it was already there :doh:

This is wonderful, exactly what I need.

phx.gen.auth has been merged and will be part of the upcoming Phoenix 1.6

This may be a non-answer answer, but given you are versed on the Phoenix front, may I suggest a book on the design aspect of things? For example, Domain Driven Design Quickly: https://www.infoq.com/minibooks/domain-driven-design-quickly...

It has been a while since I have read it, so it may be dated, but hopefully others can provide suggestions too!

Thanks :) I started reading the original DDD several years ago, but bailed out due to quite how dense it is, hopefully this summary will be a little more approachable.

Have a look at this - https://pragmaticstudio.com

They have courses on Elixir, Phoenix and today have just released a LiveView course.

Just to add to your comment: I've been running through the free LiveView course and it's been really great. I'm excited to finish it and continue with the pro one!

Just adding that I found those courses really helpful as well.

Not Jose (obviously), but I have a copy of https://pragprog.com/titles/phoenix14/programming-phoenix-1-... which I think is still fairly relevant.

Of course, there is always https://elixirforum.com and a good search :)

The book Programming Ecto [1] also has a chapter on application design which talks about contexts.

[1]: https://pragprog.com/titles/wmecto/programming-ecto/

I have that book too and it's great. Will have to check out that specific section. I mostly used it to see examples and explanations of how to do things in the Ecto DSL (which it is great for).

Yes, I read and can recommend that book as well. I wanted to get the little OTP guide too, but people say it's outdated.

Apart from books and forum though, there are many posts online! You can check ElixirStatus[0] or a new initiative called Beam Bloggers Webring[1].

[0] https://elixirstatus.com/ [0] https://beambloggers.com/

Contexts are loosely (maybe a little more than loosely) based on the Bounded Context concept in Domain Driven Design. As a good introduction, I would recommend reading Domain-Driven Design Distilled by Vaughn Vernon. It's sort of like the Cole's Notes version of the full Domain Driven Design which is a monster of a book.

Great Post José!

I remember early presentations on Elixir (I think first at Erlang DC in 2011 or 12?) and it's been great to watch Elixir mature and develop.

While I'm strongly in the Erlang camp, I do appreciate the work you and the contributors to Elixir have done for the ecosystem as a whole.

Thanks for Elixir and to the team as well for the work you put. I'm new to Elixir, had to learn it at work and it's been an interesting way to solve problems. I'm looking forward to deploying a few prototypes this year using Elixir. Thanks.

Thank you Jose for your relentless dedication to the language and community. The last year of full-time Elixir/Phoenix has been my favorite of my career, and I'm really looking forward to future of the ecosystem.

Thanks from me as well. It’s been more than 5 years since switching from Ruby and I have never regretted it. You did and continue to do great work(and whole team as well). Can’t wait for the big thing at Lambda Days!

Just wanted to say thanks for your work on Elixir. It’s been very useful and fun to use for my home grown projects.

How has the book sales been doing?