1. 17

  2. 10

    Oh boy. “Phoenix on Elixir”. As much as I love Elixir/Erlang/BEAM, it seems inevitable for the language and ecosystem to get stampeded by hyped-up Rails/web developers who think of both as the same thing. Oh well, more users means more chances of getting an Elixir job.

    The article never defined what a “modern app” is and how Phoenix makes it easier compared to Rails (which has web sockets). That said, Phoenix has the BEAM behind it and is not a majestic monolith—with umbrella applications, it can just act as your web server and have little to no business logic, so it can make large web applications easier to manage.

    1. 4

      This is valid criticism. My main focus was trying to find the parts in Rails that can be easily “translated” into Phoenix and explain those parts. I didn’t write much about BEAM and umbrella applications because there really isn’t an equivalent in Rails.

      1. 7

        Sorry if I was too hard on you—the rest of the article is excellent. It just happens that those two things really bug me :-) I definitely think umbrella applications deserve a mention, it’s a major advantage to Rails (or many other languages).

        1. 5

          No worries. I enjoy honest criticism, it helps me improve. This is my first blog post of this size, so I have plenty to learn still.

          1. 2

            For people that used both Elixir and Django: how do the Umbrella Projects relate to what django calls apps?

            1. 6

              Not really at all. I’m trying to think of any similarities but I’m currently failing; they’re closer to a package of packages. I’ll go through some reasoning:

              • A Django app is a framework construct, Elixir Umbrella’s are more core to the language itself. Every build of Elixir ships with Mix, a build tool which is capable of creating new Elixir projects. An Umbrella project is simply a root level Elixir project that contains one or more Elixir projects “under its wings”. Each Elixir project keeps it’s own dependencies, version, docs, start-up list, build, test suite, etc. Basically it lets you have a de-coupled per-app isolated layout while keeping the advantages that a single repo can give. Each app within the umbrella is individually deployable.

              • In Django, it’s quite awkward to create a 3rd-party package that runs alongside your actual project while you’re developing it. Sure it’s possible, but with Python Path and module importing issues - it tends not to happen and you end up syncing with some git remote. This problem is solved with Umbrella projects because you simply create a new Elixir project within your umbrella and list the new project as an “in umbrella” dependency to your existing project; this means that when you’re finished with development and ready to open source on Hex - all you have to do is publish it and change the dependency of your original application to point to Hex instead. And if you never finish it? It can just stay there running as it’s own self-contained app. It reduces the friction completely.

              • A Django app tends to be tightly related to a set of models and specific Django patterns. An Umbrella project is not really constrained by anything other than the standard layout of an Elixir project - which is defined by the Mix tool in every project anyway. There is no linking it with a set of data and it doesn’t take on any special extras when used with say Phoenix - it’s just a Mix project at the end of day, and any Elixir project can be one.

              To end with an example: a common pattern I take when using Phoenix is to start with an Elixir Umbrella app, and then immediately create 2 sub apps: one that contains my business logic and data stores, and the other that deals with interfacing with the web with Phoenix as a dependency. Having the separate apps helps me enforce the separation by providing a clear isolation line, and also means that I’m not glued to Phoenix. Also, while they do have separate things, if I run commands from the root Umbrella, they tend to get run on both - the integration is very nice there.

              Edit: I deliberately stayed away from OTP because I think the acronym can be off putting to newcomers but for simplicities sake, 1 Elixir project == 1 OTP app.

              1. 3

                An “umbrella project” is just multiple OTP applications in one project. They are full OTP applications, so more like a generic python package.

            2. 3

              While not really used, internal Rails Engines are equivalent to umbrella applications.

              1. 1

                I haven’t used Rails Engines in a while so I completely forgot about them. I know they can be used for similar purposes but if I recall correctly they almost become a part of the Rails monolith instead of being treated as a separate application as in Elixir. I could be wrong though.

            3. 1

              I just noticed that the title kind of suggests that the name of the framework is “Phoenix on Elixir”, which was not the intention. Sorry about that.