Because OTP comes from the Erlang world, it uses Erlang names for things. And unfortunately, some of these names are not terribly descriptive. The name application is one of these. When most of us talk about applications, we think of a program we run to do something—maybe on our computer or phone, or via a web browser. An application is a self-contained whole.
But in the OTP world, that’s not the case. Instead, an application is a bundle of code that comes with a descriptor. That descriptor tells the runtime what dependencies the code has, what global names it registers, and so on. In fact, an OTP application is more like a dynamic link library or a shared object than a conventional application.
It might help to see the word application in your head but pronounce it component or service.
For example, back when we were fetching GitHub issues using the HTTPoison library, what we actually installed was an independent application containing HTTPoison. Although it looked like we were just using a library, mix automatically loaded the HTTPoison application. When we then started it, HTTPoison in turn started a couple of other applications that it needed (SSL and Hackney), which in turn kicked off their own supervisors and workers. And all of this was transparent to us.
I’ve said that applications are components, but some applications are at the top of the tree and are meant to be run directly.
In this chapter we’ll look at both types of application component (see what I did there?). In reality they’re virtually the same, so let’s cover the common ground first.