Dependency inversion on Elixir using Ports and Adapters design pattern

Diogo Dourado — Tue, 10 Jan 2023 12:32:10 +0000

Introduction

Dependency Inversion is a well-known software development principle, described by Robert C. Martin as the responsible of systems to become flexible by making source code dependencies refer only to abstractions and not to concrete items.

Dependency Inversion demonstration taken from Clean Architecture book.

Deciding which implementation will be used in a given piece of code can be very useful and is commonly used to develop mocks on tests that involves external dependencies, such as HTTP calls or event publications.

How it is used

On Java and other object oriented programming languages the principle can be achieved using an Interface to expose desired functions and then develop a Class to implement these signatures. On the other hand, Elixir makes it possible to apply this principle by defining a set of callbacks on a Behavior and implement them on another module following the defined specification.

We can see this pattern replicated on different open source libraries of Elixir community on many use cases:

Implementation example

By deriving the Dependency Inversion principle on Elixir it is possible to implement Ports and Adapters design pattern. It consists of having a Port defining the Behaviour callbacks and the functions calling the configured Adapter implementation.

Check out this quick demonstration:

defmodule MySystem.SmsNotificationPort do
  @moduledoc """
  Sends SMS to users using configured SMS adapter.
  """

  @callback notify(user :: User.t(), message :: String.t()) :: :ok | :error

  def notify(user, message), do: impl().notify(user, message)

  defp impl, do: Application.get_env(:my_system, __MODULE__)
end

defmodule MySystem.TwillioSmsAdapter do
  @moduledoc """
  Twillio SMS adapter implementation.
  """

  @behaviour MySystem.SmsNotificationPort

  @impl true
  def notify(user, message) do
    case MySystem.HTTP.post(“http://twillio-sms.com/" <> user.phone, %{message: message}) do
      {:ok, _} -> :ok
      _ -> :error
    end
  end
end

And on config.exs we would setup:

# …

config :my_system, MySystem.SmsNotificationPort,
  MySystem.TwillioSmsAdapter

Conclusion

The same principle is used on Dependency Injection design pattern, given that you can use different implementations on a piece of your software. The difference is that Dependency Injection implementation is given on compile-time whilst Ports and Adapters is on run-time.

This means you could execute the command below on a running application and change the SMS API used on your system.

Application.put_env(:my_system, MySystem.SmsNotificationPort, MySystem.ZenviaSmsAdapter)

This is very powerful because now we are able to switch running implementations on the fly. For instance, if Twillio went through an outage we could change the SMS implementation Adapter to Zenvia resulting in our users having zero impact on their SMS messages. In the future, we could automatically detect outage events on a specific SMS adapter and switch to the other one, a pattern known as Circuit Breaker.

Understanding GenStage back-pressure mechanism

Diogo Dourado — Tue, 23 Aug 2022 01:37:00 +0000

Introduction

Back-pressure is a technique utilized to prevent an application or a piece of software of using more resources than there are available on a given infrastructure.

GenStage is an Elixir library to build complex processes divided by steps (or stages) that share data between them. This is the core behaviour used on Broadway, a multi-stage data ingestion backed on message queue systems such as Kafka, RabbitMQ and others.

The problem

Suppose you've built a news sharing system which is composed of three main components:

Data ingestor (A): constantly searches and downloads tweets that contains hashtags of interest, such as #computerscience, #architecture and #programming.
Republisher (B): takes a tweet content, renders it on several different formats (HTML, Markdown, PDF and so on) and then publishes on different platforms.
Reporter (C): writes to database the timestamps of each publishing and also exports metrics to be analyzed on the future.

The process being executed on component A is simple and takes only a single request to be done: a GET on Twitter's API. For this action we will account an imaginary measurement of 1N amount of energy to get done.

Now that a tweet content is retrieved and delivered to component B, a more complex process starts: it is required to transform the data acquired on several different formats and then make several other requests to external services (which may or not fail, timeout or take several more amount of time than usual). For this step then we will account 10N amount of energy taken.

Component C executes a simpler process as well since it only does a write operation on database and then create telemetry data that will be polled later. That's 2N amount of energy on our example.

As you can imagine, this scenario is problematic because component A generates input for component B on a speed ratio that it can't absorb, and that generates a overflow on B's execution queue.

The solution

GenStage strategy to apply back-pressure is to invert the flow direction from the producer to the consumer and so consumers now control the velocity and amount of data transmitted.

Component C starts with its execution queue empty and then asks Component B (which is a consumer-producer) to produce a piece of data.

Component B which also has it's execution queue empty now asks Component A to produce a piece of data and only then the Tweeter API is called!

The amount of data produced is back-pressured so no queues gets overflowed and that's how you have a healthy workflow on Elixir using GenStages.

DEV Community: Diogo Dourado

Dependency inversion on Elixir using Ports and Adapters design pattern

Introduction

How it is used

Implementation example

Conclusion

Understanding GenStage back-pressure mechanism

Introduction

The problem

The solution