Building Our Optional Server

Understanding processes

One of the trickiest parts of learning a concurrency-based language like Elixir is understanding when to use processes at all.

Here’s a little guidance. Consider processes when these use cases show up:

• Sharing state across processes.

• Presenting a uniform API for external services such as databases or communications.

• Managing side effects such as logging or file I/O.

• Monitoring system-wide resources or performance metrics.

• Isolating critical services from failure.

This short list is not exhaustive, but it should give us a sense of the types of things that should prompt us to think about a boundary. In short, our boundary is an optional layer of impure integration code that makes the core fast, robust, and reliable.

Processes in Mastery

For our Mastery project, a couple of those use cases ring true:

• We will need to share data across two types of state, including a repository of quizzes and the data for an individual quiz session.

• We also want to isolate failure because our overall quiz repository is a critical system and a single point of failure. If it fails, no one will be taking any quizzes!

Choosing our infrastructure

Now that we’ve decided to use processes, we need to choose between two options:

• Use our own machinery.

• Rely on other infrastructure.

We might choose the Phoenix webserver because it already has an excellent process infrastructure. In our case, we’d like to preserve the freedom to provide other types of user interfaces beyond the web, such as a possible native user interface.

---