I have some experience in both languages and have managed to do all what I used to do in Rails in Phoenix.
I need to decide which language to use for a new SaaS project which will be sold to multiple customers.
I love the ecosystem around Rails with all numerous contributed gems, everything has a gem in Rails. However, I love the speed Elixir provides.
Also, I have not managed yet to deal effectively with nested forms (and multiple children of an association) in Phoenix and to build polymorphic associations in it.
For all people who have worked with both languages, what would you recommend? Thank you.
For a B2B SaaS product, I’d evaluate how you will handle the authentication/authorisation and Multi-tenancy concerns.
Do your customers expect to use their existing enterprise SSO mechanisms? SAML libraries for elixir are fairly new.
Schema-per-tenant is supported within Ecto as a way to separate each customers data, but DB-per-tenant or row-level-security models might require some work.
I’m sure these problems have all been solved, it might just be less of an off-the-shelf hex package experience in Elixir
I know Elixir is way better, what holds me back is those missing libraries which make life easier like one to deal with nested associations in forms. Maybe it is time to just learn more about Elixir and Phoenix and deal with those barriers / yet to be learned things
Yeah, I think this is actually a benefit of not having a gem for everything—most of those gems are bad architecture. Before you know it, the shine is off the majestic monolith and you’re wondering wtf happened to the chef making your omakase.
Hope this helps! Of course this is a biased forum and we will say to use Elixir/Phoenix for everything assuming there’s not an organizational reason against it!
I think if you are looking for maintainability in long run, Elixir/Phoenix project with split to multiple apps (in umbrella or otherwise) is a great starting point. You can avoid the great rewrite, and replace the parts you need to in the future (most likely the UI). So if you are looking to build long-living project, you have to be careful with Rails as this does not give you that flexibility out of the box.
You should consider what developers you have available to help you build it. Only freshly converted Rails developers are probably not great idea for new Phoenix project, as they will keep writing Rails in Phoenix, and if you are looking to hire only locally/work from office it is going to be difficult to find suitable candidates. It’s easier if you are willing to build a remote team. If you have an existing team of Rails developers, consider getting some more experienced devs to join them mentoring at least for the first few initial months. There are individuals you can hire on a freelancing basis and consultancies alike that can help you with that (disclaimer - I run one of these myself). I am only mentioning this because I have seen this working in practice, you need best practices in Phoenix mentoring if you are freshly converted team, otherwise the project can go terribly wrong.
When it comes to nested forms, the link pasted above by @tme_317 is great starting point. Do that. In fact, I like to create such schemas for all the forms I have, and use very similar pattern for all form submits/commands. It’s like creating service objects in Rails, you move the business/validation logic one level up from the database access layer, which gives you great flexibility :).
Thank you for sharing. I see how this can help when creating new relatet records, however it seems that additional logic needs to imolementing for editing/updating/adding/ or removing nested chikdren associated with a parent record, correct?
Yes, I use this pattern with form submittals when I don’t want a 1-to-1 mapping between UI forms and the database tables and I want the whole operation to be an ACID DB transaction. As far as editing/updating/deleting nested children you will need additional logic which depends on how you are exposing that functionality.
Let’s say like in the example blog post I referenced you have Accounts which have many Users and you are using the pattern above. The RegistrationController and Multi handles creating the Account and the initial User (along with maybe some other side effects like a welcome email) in a DB transaction after that form is submitted. Later, if you want to create new child Users associated with that parent or edit/delete a User you’d use a different form API than initial registration. It could be as simple as standard CRUD functions in UserController like Phoenix generates rendering a form where you can edit the User details or delete the record.
Apologies, I’m not familiar enough with Rails to know what sort of magic may exist to potentially make nested manipulation easier.
There exists, but as you say it is magic. And this comes with all the magic issues usually comes, most notably that you can expose operations that are not safe fairly easily. It is better to do what you do and retain control over the process, even in Rails.
I simply cannot believe how simple it turned to be. I have not used any embedded schemas or formex and I have managed to deal with those nested forms perfectly. I have just built a small testing API phoenix back-end application and used VueJS on front-end. Read some documentations and made the needed code changes. Works fine
The documentation says that i need to be careful using on_replace: :delete as in: has_many :optics, Optisys.Optics.Optic, on_replace: :delete
I guess I need to allow only the user who created a parent content to update/delete its nested associations.
I love Elixir, there will be no future Rails projects for me
