Gain insights into building scalable backend applications with Elixir, OTP, and Phoenix. Learn about persistent connections via Phoenix Channels, and explore distinct, decoupled application layers.

Functional Web Development with  Elixir, OTP and Phoenix by The Pragmatic Programmer_ .png

elixir_islands_test.tar.gz

elixir-app

pheonix-app

elixir-app-guesses

island-interface

phoenix-app-compiled

phoenix-app-iex

phoenix-app-form

phoenix-app-new-module

client-connection

presence

phoenix-app-final

without-presence

Elixir and OTP provide exceptional tools to build rock-solid backend applications that scale. In this course, you’ll build a web application in a radically different way, with a backend that holds application state. You’ll use persistent Phoenix Channel connections instead of HTTP’s request-response, and create the full application in distinct, decoupled layers.

In Part 1, you’ll start by building the business logic as a separate application, without Phoenix. You’ll model the application domain with Elixir functions and simple data structures.

In Part 2, you’ll add in the GenServer Behaviour to make managing in-memory state a breeze. 

In Part 3, you’ll build a web interface with Phoenix where you’ll use Phoenix Channels to establish persistent connections between the stateful server and a stateful front-end client.

Needless to say, you’re going to love this way of building web apps!

Functional Web Development with Elixir, OTP and Phoenix

# Microservices 

Applications naturally grow and become too complex to manage easily. The impulse to break large applications into smaller, independent ones has been around a long time. Microservices are currently the most popular approach for this. However, long before microservices, there was SOA (service-oriented architecture).

Oftentimes, we need to break up larger functions into smaller ones with intention-revealing names, and then compose those functions back together to re-create the original behavior. We get the bigger picture from the recomposition, and we can dig into the details by looking at the individual functions. The same goes for breaking up large applications into services.

The key to this recomposition for services is communication. Since services are separate, they need an external mechanism to talk to each other. Most often, this is an HTTP request from one service to another. However, it can also be a message queue like RabbitMQ or a streaming log like Kafka.

This separation—and need for communication—is exactly the source of all the benefits as well as all the problems associated with breaking an application into services. 

Let’s take a closer look at both sides of the microservices coin.

# Advantages

- The forces that push developers to reach for services are direct and easy to enumerate—the need for focus, encapsulation, and scale.

- Unix taught us the virtue of doing one thing and doing it well. A code segment that is smaller and more focused is easier to write and maintain. Unix also taught us that we can compose smaller commands together to build more complex behavior. These same ideas can also be applied to services.

- Well-designed services hide all their data and implementation details behind a public interface. This allows us to change the implementation behind the scenes as much as we need as long as we preserve the contract of the interface.

- Different parts of a monolithic application often have very different resource needs. By breaking applications up into services, we can address those needs individually on a service-by-service basis.

# Disadvantages 

The benefits services provide come at a cost, and that cost can be high.

- Development, testing, and deployment all become more complex. Handling failure when a service crashes or loses communication over the network takes extra thought, preparation, and work.

- Development and testing pose similar problems. When services depend on one another for the full application to work, we either need to start all the services up for the system to work, or we need to provide mock services instead.

- If we choose to use live services, we need to keep the versions up to date. If we choose mock services, we need to make sure they haven’t drifted and still accurately represent the real service.

- Deployment is vulnerable to the versioning problem as well. Managing version changes across multiple services requires careful planning. Handling breaking changes to one service means we’ll need to update others that depend on it. That often leads to multiple deployments at once to keep the whole system consistent.

- We also need a new strategy for cross-service fault tolerance—how we keep other services running when one of the services is down or unavailable. A circuit breaker pattern is one way of ensuring this.

- Circuit breakers monitor external calls for failure or timeouts. They keep the whole system from failing by providing predetermined responses instead of crashing. They may also implement retry strategies to determine when a failed service comes back.

- One of the biggest disadvantages is determining where to break a monolith apart. Unlike object-oriented (OO) design and refactoring, we don't have a well-defined language of patterns we can rely on to make these decisions yet.

- In OO design or refactoring, we have language-level structures appropriate for the job, such as classes, methods, modules, and functions. However, when we break a monolith into services, most languages don’t have constructs at the scale needed to hold a service.

Other languages and ecosystems offer solutions to these problems, but the solutions often add complexity and friction to our workflow. In the Erlang and Elixir ecosystems, OTP provides solutions without the extra overhead.

A Look at Microservices

Introduction

Mapping Our Route

Model Data and Behavior

Working of State Machines

Add OTP for Concurrency and Fault Tolerance

Process Supervision for Recovery

Generate a New Web Interface with Phoenix

Create Persistent Connections with Phoenix Channels

Appendix

A Look at Microservices

Microservices