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?