By day I’m a Ruby dev, I’ve taken a few days off work to work through all the stacked up Elixir books I have and I’m really just hoping to deep dive into Elixir and to knock out an application. I’ve been working through the Programming Phoenix book and I’m wondering if the code quality is what you’d expect in your average Phoenix project rather than a play project like the one you build in here.
I’m seconds guessing if the code is dumbed down for new users and overly explicit. If the Context(s) are too much, I’ve got so many files open and getting muddled just trying to work on with a single controller. There are lots of different ways to say authenticate a user on a controller, and it’s really interesting to see but am I getting more options than I need?
There’s a case where the select options for a Category select tag are loaded in a plug defined in a controller, and then the options are extracted in a Context, rather say in a View which seems more appropriate?! Or is the view avoiding touching the database at all.
Then when it comes to testing a controller, the examples seem way too much. e.g. VideoControllerTest where every action is tested to suggest that the user should be logged out. I get it a bad actor could try every route. But is this just for completeness and to prove what you can do?
To some degree I’m expecting to find all the familiarity and equivalents that I use with Rails in just one book, which is probably insane. So far I’m creating objects with basic scaffolds and I’m reaching for the equivalent of nested attributes already because I know my interface isn’t going to be quite so simplified.
Anyway…I’m not really sure what my point is. Is this book a good book to build a project alongside or just to fire out the possibilities and off you go to kill a bear in the woods with your new weapons?
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
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.
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).
I loved PragDave way because I was already doing this type of approach in PHP, where I would have an entrypoint to the code core (application in the Elixir course) that could then be used from Controllers, CLI, Websockets, or whatever interface we would decide to use, and they were packaged as vendor dependencies, instead of being stuffed inside the Laravel Framework. This approach had the advantage of being a lot easier to upgrade Laravel versions, because the framewrok was just being used as a placeholder to bootstratp and run our code from the vendor folder.
