Do you rate the Programming Phoenix book?

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.

I feel the desire to refactor what I have already, and I don’t know if that’s arrogant and not really buying into a new way of thinking about code and a different way to organise. I almost feel like the author is daring me to refactor it in order to learn as I do. Perhaps I’m being negative, I’ve learned an awful lot from this already and that’s the main takeaway.

I’m going to pause half-way to duck into the Ecto book because I’ve already come across problems with trying to construct queries with pipes which deviate from the examples I’ve already got.

It’s weird to feel so out of my depth on something that feels so familiar. I’ll take a look at those two resources. Thank you

are you familiar with Elixir or any functional language?
Or is it your “first” try and at the same time you are trying to learn Elixir, Phoenix, Ecto?

Because despite them being the de-facto stack people use, you have a new language and 2 different libraries that focus on different things

Contexts are an abstraction over multiple modules, so if you don’t need it why don’t you just have 1 module with the functions you need?

Probably you are trying to learn multiple new things at once and you are overwhelmed.

The main difference with Ruby, and it is a huge difference, it’s about Functional Programming.

While the syntax is similar, It’s difficult to think OOP with Elixir.

You have a lot of small, composable functions, You will find a lot of indirections, duplications, and typically, web does not know about db, while the app does not care about the web.

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.

It’s more likely than you think

https://phoenixforrailsdevelopers.com/

I found this incredibly useful when getting started with Phoenix a few years ago.

Elixir is my first functional language and I get the differences. I think this is .ore about organisation and naming conventions than anything else. Separation of View from DB is something I would normally avoid. But the Context examples for a Category select feel awkward and contrived.

I’m new I can accept the way they are done here but I can also see there are many ways the achieve the same goal and reuse code in different contexts which is wonderfully flexible.

I am liking my journey, and the Elixir errors are so nice that I can trace my mess ups with confidence already

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.

Sorry, to clarify. The equivalent of a View in Rails is a Helper which makes methods available to the template. I wouldn’t generally fetch from the database in a Helper/View, but Rails does rather lazily encourage you to because of the lack of extraction between a Class and the equivalent to a Context. I guess Service is a good analogy, but normally I would expect a service to have a dedicated responsibility that wraps a complex DB interaction in a simple interface.

Interesting, if I think in terms of trying to keep the complexity of communicating with the DB in a Context then actually yes that makes more sense.

Completely agree on the PragDave course. It really solidified my thinking on how to work with Elixir code.

When you go from Rails to Phoenix you’re often mentally in this space of thinking you are building “another web app on a different framework”.

When you are done with the course you’ll realize that the Elixir approach is to build your application on its own and then the web app becomes one of many possible interfaces to the actual application. It’s so much cleaner, more maintainable and easily testable that once you get the hang of it you’ll never want to go back (in my experience at least).