I extended the app built on the book and this is the result https://video-hub.exadra37.com/

Screenshot from 2022-04-01 18-56-151200×648 72.1 KB

The code is the way it is encouraged by the creator of the framework, that is present in all the mix Phoenix generators.

Personally I dislike the approach and by far I prefer @PragDave approach that resembles my old Resource Action Pattern approach to structure code in a clean and efficient way, but this affirmations are always relative, and many may disagree.

I would recommend you to take the Elixir for Programmer 2 video course, and see by yourself what it looks like to organize and segment your code in a much clean way and with the Single Responsibility Principle in mind.

Haven’t read that book, but if you are coming from Ruby/Rails as I did, you will probably find the “blessed path” in Elixir/Phoenix a bit heavy at first. Rails by default is a real lean MVC pattern but Phoenix encourages something more like a S(chema) C(context) C(controller) V(iew) T(emplate), with similar separation conventions as you would expect in Rails to see between V/M (formatting in a model? db calls in a view? no).

But as others have pointed out compared to Rails, Phoenix is far lighter when it comes to imposing this convention. It is fairly easy to break convention and institute your own patterns. In Rails if you move a file or even just name it slightly wrong, it can act as if it doesn’t even exist. Phoenix doesn’t care where your modules are or what they are called. It exposes way more in terms of request processing and templating logic so you can easily make it behave however you want.

Personally, I don’t see a need for views/templates in my RESTful API only application. And I use contexts as namespaces, I don’t hesitate to put business logic specific to a single schema in the schema module (or child modules)–even if I need to query the db there. I have found this to be a bit more of a challenge with teams, since Rails strong conventions left little room for contention, you had to have a very compelling reason to follow a different pattern and you needed to identify it very early on in the dev process. In Phoenix people tend to approach everything slightly differently, not as crazy as the JS world, but definitely more variation between Phoenix projects than Rails in my experience.

I want to mention that i don’t have a ruby/rails background

Separation of View from DB is something I would normally avoid.

Is this common in rails? Because in other languages/framework it’s very common to seperate your view from your database.

many ways the achieve the same goal

Isn’t this one of the biggest problems when writing ruby?

Of course you can have contexts that abstract things, but if you don’t need contexts don’t use them

You can do Repo.all(Users) in your view if you would like, but this creates problems as the codebase grows. That what contexts solve essentially.

Contexts are similar to Controller -> Service -> Repository pattern in my view which is used a lot.

As i mentioned previously, if your intentions are to learn phoenix and elixir, don’t focus on contexts. You will use them when you will meet the problems that they are intented to solve, but if you still don’t like them you can just ignore them. It’s not enforced.