Applications

Despite the name, Applications are not what we normally think of as software applications. They are reusable units of code that are bigger than modules. In fact, they most often contain multiple modules. They’re similar in scale to libraries in other ecosystems. While they can function as libraries, they can also be much more.

Applications can act as the true building blocks for our programs and a means of putting together integral pieces of business logic to build a larger whole. Working with larger building blocks like these makes us really productive.

IslandsEngine Application

Applications can also stand on their own as what we traditionally call an application. The IslandsEngine Application we developed in the first part of the course is one example. It is a fully functioning game, albeit with an unfriendly user interface. As complete as it is, we can still use it as a building block for something larger, as we’ll soon see.

The :application Behaviour is a specific OTP Behaviour written in Erlang, just like :gen_server. There is a module in OTP that defines :application-specific functions as well as a list of callbacks we need to implement. Elixir provides a wrapper module around the pure Erlang module called Application. We’ll use the Elixir wrapper most often.

The Application Behaviour lets us do three things. It lets us define and name Applications. It facilitates dependency management among Applications. We can define hierarchies of Application dependencies and the Behaviour will make sure they work correctly. The Behaviour also facilitates cleanly starting and stopping individual applications in a running BEAM.

“Cleanly” means two things here. It makes sure to start any dependent Applications before it starts itself. It also keeps track of any processes the Application spawns during startup or while it’s running. It is sure to stop them when the Application stops.

Now that we have an idea of Applications’ significance, let’s dig a little deeper and see how they work.

Understanding Applications

The good news is that we’ve been working with an Application all along. At the beginning of the course, when we generate the brand-new IslandsEngine project, Mix automatically creates it as an Application. We didn’t need to look deeply at the Application Behaviour because IslandsEngine stood on its own for our purposes.

Although, now we need to use it as a dependency, as a building block to create a larger project—the web interface. Understanding Application dependencies will clarify our work on this project and any other Elixir projects we work on.

We already have examples of the Application Behaviour–related files in IslandsEngine. We use them to understand dependency management and to start or stop individual applications inside the BEAM. We’ll see the independence of Applications firsthand that lets us solve the coupling problem so prevalent in web applications.

There are three parts to the implementation of an Application, and Mix is involved in all of them.

When we generate a project with mix new, we get a file named mix.exs at the root of our project. The mix.exs file defines key aspects of the Application, everything from its name and version number to a list of applications it depends on to build the project.

Mix also generates a Behaviour callback module in the /lib directory that is named after our project. In the case of our game engine, it generates /lib/islands_engine/application.ex. If we supply the --sup flag to mix new, the callback module will contain the start/2 callback function necessary to start the top-level supervisor for the Application. Without --sup, the file will be there but will be empty.

Once we compile the project, Mix generates an application resource file, written in Erlang. The BEAM will use this file to work with our Application.