I was talking to a coworker earlier this week who I am showing elixir and he said to me:
Well, this is all very cool and all, but everything I see people doing is so complicated!
I dont need all this concurrency and OTP and nine 9's.
If I'm not using that why leave rails/laravel/django for phoenix?
I said that even if elixir didnt had such advanced and useful things I would still use it because I really like the syntax, the functional approach (this is my first FP language and it changed so much the way I develop in other languages) and Ecto.
Is Phoenix overkill for āsimpleā projects - most likely. But CRUD solutions are all you can see (or imagine) if you always implement CRUD. Even if the judgement right now to use a CRUD solution is a correct one, one has to deal with the consequences of that choice in the future.
So everything is fine when everything stays the same - but in the software world there arenāt many things that donāt change and business change has been emboldened by software.
Phoenix gives you the flexibility to change away from the CRUD model when the time comes. However flexibility comes with the price of added complexity and additional lines of code - but at least you have a solid foundation that remains maintainable and sustainable should you need to move away from the CRUD model.
With a CRUD system doing non-CRUD things will invariably lead to a complex, unmaintainable mess - and the deeper you get into that mess the more work it will be later when somebody finally pulls the trigger to re-implement everything in with a non-CRUD framework. So if you choose a CRUD framework be prepared to bail at the first sign that CRUD may not be enough.
Back in 2005 I had exactly the opposite experience. I tried the Rolling with Ruby on Rails tutorial - but the moment I became aware of the core importance that ActiveRecord played, how it completely entangled persistence concerns with domain concerns for the sake convenience, I was out.
In my experience data-at-rest and data-in-motion are often two completely different animals, so I always like to have the option of divorcing my data schema from my persistence schema.
With Phoenix the web interface is a separate concern from your application and that is the way I like it.
I have a couple of pure CRUD things in Phoenix that android apps talk to (like one that controls my lights whoo!). Making a new one that uses absinthe instead though, GraphQL is really so so much better than CRUD, so much faster and more efficient and less trips and and andā¦
I think you are highlighting another aspect - rather than dealing with a database directly, applications are more and more accessing services to handle data and often the application cannot dictate the shape of the data itās dealing with.
For my Light server, I have bluetooth LED multi-color lights in my house and my home server has a bluetooth adapter that talks to and controls them, a phoenix webserver talks to it, I just send tokens over https to certain endpoints to query state and to update colors and brightness and such to each ānamedā bulb. The original software for the light was phone-only and was utter shite, hence I rebuilt it to handle auto-turning on lights when I get home, turning them slowly red into the evening/night until they turn off, etcā¦ etcā¦
Iām not, but it might be interesting to be informed a bit about task-driven uiās: http://www.uxmatters.com/mt/archives/2014/12/task-driven-user-interfaces.php
Iām currently doing a freelance job (not elixir allas, there are almost no freelance jobs for that in my country) at a company where they have all sorts of problems thanks to their giant crud app where customers are not guided through their processes. They are interested in task-driven uiās.
I get what you mean. My current project is a āsimple CRUDā to map some raw queries to specific client databasesā¦ and to run those queries too, and manage then on a queue, and parse the response, and check the status of the connectionā¦
I can do it with the current stack (php), but somethings are awful
My 2 cents : having the type of system and reliability that Elixir give you make building a CRUD app easier and cheaper, because it forces you to do it ābetterā.
I consider it a bit like safety in a safety critical system. The earlier you add the safety thinking, the less expensive the system is, even the unsafe one. Because it allows you to cut corner easily, as you know that you are safe.
My response would have been it is better to have the option to implement these seemingly more complex features than to not have them at all. In the off chance your application does need to scale, Elixir/Phoenix can really lessen the burden. And who wouldnāt love the concept of fault tolerance?
Iāll agree that some of these things may be overkill in the beginning (like when prototyping your app), but really I would rather have all the options available to me. This is one of the reasons why I made the switch myself.
But what if one day they do need an app like that? Wouldnāt they rather be able to use Phoenix with competency or would they prefer to be a beginner for such an important app? And what if their apps do take off - what will they do then?
My first Phoenix project is going to be a basic CRUD style app because I am hoping to learn a lot from the experience, enough to hopefully put to good use for future apps that are going to be much more complex and in need of the scalability that Elixir affords us.
There are of course other reasons but perhaps this one might not be so obvious.
I just started converting some of my python CRUD apps to phoenix. Iāve wanted to convert them to Erlang/OTP for a long time and started on erlang ports but the erlang has not focused on traditional web apps. Finally with phoenix 1.3 and ecto 2.0 I think phoenix is mature enough for me to use it.
From my point of view, anything but the simplest CRUD app where your forms and models precisely match what you have in a database you are going to have to write custom code anyway. And erlang/elixir/OTP bring more to the table than only better performance and concurrency.
OTP applications make it easier to modularise your code and keep well defined API. Which in turn makes everything easier to maintain and modify
OTP releases are powerful and a great way to drop a self-contained package that can run your release. It also enables hot-upgrades (but for a simple CRUD app that is likely not needed)
Production trouble-shooting. Thanks to being able to connect to the Erlang Virtual Machine you can see what is actually going on and trace functions and processes. This is very useful not only during development but to quickly find problems in your production system.
Being a functional language gives you the ability to write pure functions. This makes your system so much more robust. It takes a bit of practice though to think this way as erlang/elixir allows for side-effects in code.
iām still learning elixir/phoenix, going through the books and all but iām having trouble seeing why phoenix is more complicated than others for even simple crud apps. The phoenix command line helpers pretty much generate everything for basic crud. granted i havenāt touched ruby but this seems super easy and simple. is there any cases where those other languages trump elixir in any way?
Not the languages or frameworks directly, but the ecosystem geared towards web development on ruby is huge.
I agree with you that developing a simple crud with phoenix is very easy.