OTP Solutions

OTP

OTP stands for Open Telecom Platform. The name reflects Erlang’s origin in the telecom industry at Ericsson. In practice, OTP is much more general than the name suggests. We can build any application with OTP.

OTP is Erlang’s comprehensive standard library. It includes several software tools and a set of design patterns. Together, these are a treasure trove of collected wisdom and best practices to build concurrent and fault-tolerant programs in Elixir and Erlang.

OTP’s toolset is extensive. It includes an in-memory key-value store (ETSErlang Term Storage), a relational database (Mnesia), monitoring and debugging tools (Observer, Debugger), a release management tool (Reltool), and a static analysis tool (Dialyzer). The list goes on. We won’t cover each of these here, but it’s good to know that they are there if you need them.

One of the most common and powerful tools OTP provides are the design patterns called Behaviours. Two Behaviours, GenServer and Application, give us much of what we want from microservices without the problems.

We’ll take a look at those in just a minute, but first, let’s see what Behaviours are all about.

Behaviours

For the next few lessons, we’re going to cover numerous OTP Behaviours. It is difficult to come up with a concise explanation of OTP Behaviours. In concrete terms, they are modules in OTP and modules that we define in our Elixir applications. However, they are also design patterns that reflect best practices. The rest of this section should clear things up.

Behaviours grew out of early Erlang developers’ experiences at Ericsson. Concurrency is hard and fault tolerance is complex. The Erlang team put a lot of work into getting them right. Behaviours standardize the best practices and make them easy to use in our applications.

Explanation of Behaviours with OTP

OTP defines Behaviours for different types of specialized processes we can use to build our applications. We’ve already mentioned GenServer and Application, but there are others. There’s one for finite state machines, one for creating and handling system events, and one for creating supervisors for fault tolerance. We can also define our custom Behaviours to work in our domains if we need to.

Each Behaviour is a module in OTP that contains the standard code necessary for a process of that type. A GenServer, for instance, needs to be able to start new server processes, hold state, handle synchronous calls with a return value, and handle asynchronous casts without a return. The Behaviour module defines all that wiring and plumbing.

For real applications, the wiring and plumbing are not enough. We need to customize a GenServer to handle particular requests our applications require.

Fortunately, there’s an easy way to do this. We start by defining a standard module in our application. Then, we inject the Behaviour module code into our new module. A Behaviour stores a list of callbacks specific to it. – Modules like ours need to implement these callbacks to be an instance of that Behaviour. By writing those callbacks with code specific to our application, we customize our implementation of the Behaviour to work precisely the way we need it to.

That’s the process we’ll follow to build a GenServer for Islands.