Book Image

Mastering Elixir

By : André Albuquerque, Daniel Caixinha
Book Image

Mastering Elixir

By: André Albuquerque, Daniel Caixinha

Overview of this book

Running concurrent, fault-tolerant applications that scale is a very demanding responsibility. After learning the abstractions that Elixir gives us, developers are able to build such applications with inconceivable low effort. There is a big gap between playing around with Elixir and running it in production, serving live requests. This book will help you fll this gap by going into detail on several aspects of how Elixir works and showing concrete examples of how to apply the concepts learned to a fully ?edged application. In this book, you will learn how to build a rock-solid application, beginning by using Mix to create a new project. Then you will learn how the use of Erlang's OTP, along with the Elixir abstractions that run on top of it (such as GenServer and GenStage), that allow you to build applications that are easy to parallelize and distribute. You will also master supervisors (and supervision trees), and comprehend how they are the basis for building fault-tolerant applications. Then you will use Phoenix to create a web interface for your application. Upon fnishing implementation, you will learn how to take your application to the cloud, using Kubernetes to automatically deploy, scale, and manage it. Last, but not least, you will keep your peace of mind by learning how to thoroughly test and then monitor your application.
Table of Contents (18 chapters)
Title Page
Dedication
Packt Upsell
Contributors
Preface
5
Demand-Driven Processing
Index

A window to your nodes


Before we devise a way to look at and interact with our remote application, let's analyze how Elixir, given its Erlang heritage, works in a distributed environment. When you run an IEx shell or the ElixirDrip release, an Erlang VM starts. Each VM is called a node, and you can have many nodes running on the same computer.

To start a node, you define its name and magic cookie, and the node then tries to register itself on the local Erlang Port Mapper Daemon (EPMD). This EPMD is a kind of name server that by default runs on port 4369 and registers which nodes are running in each host.

Note

The cookie is indeed described as magic; check out the Erlang documentation at http://erlang.org/doc/reference_manual/distributed.html. Whoever knows the cookie value is able to connect to the nodes using it, no questions asked, so it's really important it is long and stored in a secure way. By default, Erlang forms clusters of nodes in clear, because it is assumed the cluster runs on...