DEV Community: Herminio Torres

Bridging the Gap: Simplifying Live Component Invocation in Phoenix LiveView

Herminio Torres — Wed, 04 Dec 2024 14:54:05 +0000

Inspired by a conversation on Bsky (Thanks Netto) about the release of Phoenix LiveView 1.0.

The release of Phoenix LiveView 1.0 was announced yesterday! Hooorayyy! 🎉🥳

With numerous improvements aimed at simplifying the framework’s usage. One of the major enhancements stand out: the move from <%= %> to {} for rendering templates.

And I missed one more enhancements in terms of ergonomics when is calling components. Calling functional components in Phoenix LiveView is straightforward and seamless, making the developer experience intuitive. However, when dealing with live components, the syntax and approach differ significantly. This inconsistency can disrupt the ergonomics of the framework, especially for newcomers or teams striving for code simplicity and uniformity.

Here’s an example to ensure we’re on the same page and to illustrate the topic I’d like to explore further in this blog post.

Function Component

defmodule MyComponent do
  # In Phoenix apps, the line is typically: use MyAppWeb, :html
  use Phoenix.Component

  def greet(assigns) do
    ~H"""
    <p>Hello, {@name}!</p>
    """
  end
end

<MyComponent.greet name="Jane" />

Live Component

defmodule HeroComponent do
  # In Phoenix apps, the line is typically: use MyAppWeb, :live_component
  use Phoenix.LiveComponent

  def render(assigns) do
    ~H"""
    <div class="hero">{@content}</div>
    """
  end
end

<.live_component module={HeroComponent} id="hero" content={@content} />

I'll present a solution, hack—that bridges, enabling a more cohesive and developer-friendly way to invoke live components. By aligning the ergonomics of both functional and live components.

defmodule HeroComponent do
  # In Phoenix apps, the line is typically: use MyAppWeb, :live_component
  use Phoenix.LiveComponent

+  def call(assigns) do
+    ~H"""
+    <.live_component module={__MODULE__} {assigns}/>
+    """
+  end

  def render(assigns) do
    ~H"""
    <div class="hero">{@content}</div>
    """
  end
end

Here’s how you can call it:

<HeroComponent.call id="hero" content={@content} />

The next step for this implementation is to encapsulate it in a macro, allowing you to reuse it wherever needed.

Taming data with Ecto.Enum and Ecto.Type

Herminio Torres — Wed, 22 May 2024 12:53:35 +0000

Let's take advantage of Ecto.Enum and Ecto.Type.

The schema:

defmodule Blog.Category do
  use Blog.Schema

  schema "categories" do
    field(:name, Ecto.Enum, [:til, :elixir, :ecto])
  end
end

Divide & Conquer with Reflections and Ecto.Type.load/3:

iex> type = Blog.Category.__schema__(:type, :name)
{:parameterized, Ecto.Enum,
 %{
   mappings: [til: "til", elixir: "elixir", ecto: "ecto"],
   on_cast: %{"til" => :til, "elixir" => :elixir, "ecto" => :ecto},
   on_dump: %{til: "til", elixir: "elixir", ecto: "ecto"},
   on_load: %{"til" => :til, "elixir" => :elixir, "ecto" => :ecto},
   type: :string
 }}
iex> Ecto.Type.load(type, "unknown")
:error
iex> Ecto.Type.load(type, "ecto")
{:ok, :ecto}
iex> Ecto.Type.load(type, :ecto)
:error

In the meantime:

iex> Ecto.Enum.values(Blog.Category, :name)
[:til, :elixir, :ecto]
iex> Ecto.Enum.dump_values(Blog.Category, :name)
["til", "elixir", "ecto"]
iex> Ecto.Enum.mappings(Blog.Category, :name)
[til: "til", elixir: "elixir", ecto: "ecto"]

Also, another great resource from German Velasco where he wrote Richer domain types with Ecto custom types

Happy Hacking!

Troubleshooting MacOS Performance: Addressing fseventsd Issues Causing Memory Leaks and Sluggish Performance

Herminio Torres — Wed, 24 Jan 2024 15:52:31 +0000

The fseventsd process on macOS is part of the operating system's infrastructure for handling file system events. This daemon is responsible for monitoring changes in the file system and reporting these changes to applications that need to be aware of them.

The fseventsd process keeps track of changes in directories and files. It plays a crucial role in various system functions and applications, including file synchronization, automatic backups, search indexing, and other processes that depend on up-to-date information about the file system.

Theoretically, the fseventsd process should not cause memory leaks when moving many files on the disk.

In recent days, I noticed my laptop was running painfully slow. Determined to get to the bottom of it, I opened the Activity Monitor to pinpoint the processes hogging an absurd amount of RAM and CPU. To my surprise, the main culprit was fseventsd. This brought back memories of a similar issue I faced before, prompting me to delve into resolving this memory-leaking puzzle again.

The root of the problem, in every instance of encountering memory leaks, is traced back to related activities involving the shuffling of a substantial number of files back and forth—an attempt to tidy up files into their respective folders and directories.

To assist "Future Herminio" in handling this issue if it resurfaces, I've decided to document the cause and solution.

The fix is refreshingly simple: open the Activity Monitor, locate/search for fseventsd, halt the process, and patiently wait for it to restart gracefully.

Exploring the Data Analysis: From Python Certification to the Elixir Challenge - Mean-Variance-Standard Deviation Calculator

Herminio Torres — Wed, 27 Dec 2023 12:50:00 +0000

Recently, I embarked on a learning journey, delving into Data Analysis and Data Science. Using tools such as Python, Numpy, Pandas, Matplotlib, and Seaborn, I decided to solidify my knowledge by undertaking the Data Analysis course at freeCodeCamp, aiming to achieve my first certification.

Simultaneously, I introduced myself to the universe of Elixir Nx. In this new journey, I explored tools like Nx, Explorer, and VegaLite, promising to add a unique dimension to my data analyses.

I will share a detailed tutorial in an upcoming post, providing practical insight into their application.

After completing the certification using Python, the idea of embracing a new challenge, I decided to tackle data analysis problems using the Elixir toolset exclusively.

My first project in this new phase is the Mean-Variance-Standard Deviation Calculator. An exciting opportunity to apply newly acquired concepts and explore the effectiveness of Elixir in handling complex statistical analysis challenges.

By sharing this experience, I hope to document my progress and encourage other enthusiasts to explore multiple languages and tools on their data analysis journey. I am eager to share the results and lessons learned throughout this exciting transition from Python to Elixir. Stay tuned for more updates and practical tutorials!

Setup

Mix.install([
  {:nx, "~> 0.6.4"}
])

Challenge

Mean-Variance-Standard Deviation Calculator.

Create a function named calculate() in the MeanVarStd module that uses Elixir Nx to output the mean, variance, standard deviation, max, min, and sum of the rows, columns, and elements in a 3 x 3 matrix.

The input of the function should be a list containing 9 digits. The function should convert the list into a 3 x 3 numerical array, and then return a map containing the mean, variance, standard deviation, max, min, and sum along both axes and for the flattened matrix.

The returned dictionary should follow this format:

%{
  mean: [axis1, axis2, flattened],
  variance: [axis1, axis2, flattened],
  standard_deviation: [axis1, axis2, flattened],
  max: [axis1, axis2, flattened],
  min: [axis1, axis2, flattened],
  sum: [axis1, axis2, flattened],
}

If a list containing less than 9 elements is passed into the function, it should raise a ValueError exception with the message: "List must contain nine numbers." The values in the returned map should be lists and not numerical arrays.

For example, calculate([0,1,2,3,4,5,6,7,8]) should return:

%{
  mean: [[3.0, 4.0, 5.0], [1.0, 4.0, 7.0], 4.0],
  variance: [
    [6.0, 6.0, 6.0],
    [0.6666666666666666, 0.6666666666666666, 0.6666666666666666],
    6.666666666666667
  ],
  standard_deviation: [
    [2.449489742783178, 2.449489742783178, 2.449489742783178],
    [0.816496580927726, 0.816496580927726, 0.816496580927726],
    2.581988897471611
  ],
  max: [[6, 7, 8], [2, 5, 8], 8],
  min: [[0, 1, 2], [0, 3, 6], 0],
  sum: [[9, 12, 15], [3, 12, 21], 36]
}

Solution

Create a custom exception:

defmodule ValueError do
  defexception message: "bad argument in arithmetic expression"
end

The MeanVarStr module:

defmodule MeanVarStd do
  def calculate(list) do
    if length(list) == 9 do
      tensor =
        list
        |> Nx.tensor()
        |> Nx.reshape({3, 3})

      %{
        mean: mean(tensor),
        variance: variance(tensor),
        standard_deviation: standard_deviation(tensor),
        max: max(tensor),
        min: min(tensor),
        sum: sum(tensor)
      }
    else
      raise ValueError
    end
  end

  defp mean(tensor) do
    [
      tensor
      |> Nx.mean(axes: [0])
      |> Nx.to_list(),
      tensor
      |> Nx.mean(axes: [1])
      |> Nx.to_list(),
      tensor
      |> Nx.mean()
      |> Nx.to_number()
    ]
  end

  defp variance(tensor) do
    [
      tensor
      |> Nx.variance(axes: [0])
      |> Nx.to_list(),
      tensor
      |> Nx.variance(axes: [1])
      |> Nx.to_list(),
      tensor
      |> Nx.variance()
      |> Nx.to_number()
    ]
  end

  defp standard_deviation(tensor) do
    [
      tensor
      |> Nx.standard_deviation(axes: [0])
      |> Nx.to_list(),
      tensor
      |> Nx.standard_deviation(axes: [1])
      |> Nx.to_list(),
      tensor
      |> Nx.standard_deviation()
      |> Nx.to_number()
    ]
  end

  defp max(tensor) do
    [
      tensor
      |> Nx.reduce_max(axes: [0])
      |> Nx.to_list(),
      tensor
      |> Nx.reduce_max(axes: [1])
      |> Nx.to_list(),
      tensor
      |> Nx.reduce_max()
      |> Nx.to_number()
    ]
  end

  defp min(tensor) do
    [
      tensor
      |> Nx.reduce_min(axes: [0])
      |> Nx.to_list(),
      tensor
      |> Nx.reduce_min(axes: [1])
      |> Nx.to_list(),
      tensor
      |> Nx.reduce_min()
      |> Nx.to_number()
    ]
  end

  defp sum(tensor) do
    [
      tensor
      |> Nx.sum(axes: [0])
      |> Nx.to_list(),
      tensor
      |> Nx.sum(axes: [1])
      |> Nx.to_list(),
      tensor
      |> Nx.sum()
      |> Nx.to_number()
    ]
  end
end

Test

ExUnit.start(auto_run: false)

defmodule ExampleTest do
  use ExUnit.Case, async: false

  # @tag :skip
  test "Expected different output when calling 'calculate()' with '[2,6,2,8,4,0,1,5,7]'" do
    actual = MeanVarStd.calculate([2, 6, 2, 8, 4, 0, 1, 5, 7])

    expected = %{
      max: [[8, 6, 7], [6, 8, 7], 8],
      mean: [
        [3.6666667461395264, 5.0, 3.0],
        [3.3333332538604736, 4.0, 4.333333492279053],
        3.8888888359069824
      ],
      min: [[1, 4, 0], [2, 0, 1], 0],
      standard_deviation: [
        [
          3.0912060737609863,
          0.8164966106414795,
          2.943920373916626
        ],
        [
          1.8856180906295776,
          3.265986442565918,
          2.494438409805298
        ],
        2.6434171199798584
      ],
      sum: [[11, 15, 9], [10, 12, 13], 35],
      variance: [
        [
          9.555554389953613,
          0.6666666865348816,
          8.666666984558105
        ],
        [
          3.555555582046509,
          10.666666984558105,
          6.222222805023193
        ],
        6.987654209136963
      ]
    }

    assert actual == expected
  end

  # @tag :skip
  test "Expected different output when calling 'calculate()' with '[9,1,5,3,3,3,2,9,0]'" do
    actual = MeanVarStd.calculate([9, 1, 5, 3, 3, 3, 2, 9, 0])

    expected = %{
      max: [[9, 9, 5], [9, 3, 9], 9],
      mean: [
        [
          4.666666507720947,
          4.333333492279053,
          2.6666667461395264
        ],
        [5.0, 3.0, 3.6666667461395264],
        3.8888888359069824
      ],
      min: [[2, 1, 0], [1, 3, 0], 0],
      standard_deviation: [
        [
          3.0912060737609863,
          3.399346351623535,
          2.054804801940918
        ],
        [3.265986442565918, 0.0, 3.858612298965454],
        3.034777879714966
      ],
      sum: [[14, 13, 8], [15, 9, 11], 35],
      variance: [
        [
          9.55555534362793,
          11.555556297302246,
          4.222222328186035
        ],
        [10.666666984558105, 0.0, 14.888888359069824],
        9.20987606048584
      ]
    }

    assert actual == expected
  end

  # @tag :skip
  test "List must contain nine numbers." do
    assert_raise ValueError, "bad argument in arithmetic expression", fn ->
      MeanVarStd.calculate([2, 6, 2, 8, 4, 0, 1])
    end
  end
end

Execute Test

PS: Remember to remove the @tag :skip.

ExUnit.run()

...
Finished in 0.00 seconds (0.00s async, 0.00s sync)
3 tests, 0 failures

Randomized with seed 433319

You can check out my livebook solution.

Using the Keyword module for options

Herminio Torres — Tue, 26 Dec 2023 12:44:45 +0000

It would be best if you considered using Keyword.fetch!/2 and Keyword.get/3 for options to APIs.

Without options

defmodule MyApp do
  def config(name, author \\ "Herminio Torres", description \\ "Description") do
    %{
      name: name,
      author: author,
      description: description
    }
  end
end

iex> MyApp.config
config/1    config/2    config/3
iex> MyApp.config("my_app")
%{
  author: "Herminio Torres",
  description: "Description",
  name: "my_app"
}
iex> MyApp.config("my_app", "Change")
%{
  author: "Change",
  description: "Description",
  name: "my_app"
}

Creates a config function with many arities
You must pass all parameters when you intend to change just the last default argument.

With Options

defmodule MyApp do
  def config(opts) do
    name = Keyword.fetch!(opts, :name)
    author = Keyword.get(opts, :author, "Herminio Torres")
    description = Keyword.get(opts, :description, "Description")

    %{
      name: name,
      author: author,
      description: description
    }
  end
end

iex> MyApp.config([])
** (KeyError) key :name not found in: []
    (elixir 1.12.3) lib/keyword.ex:420: Keyword.fetch!/2
    iex:3: MyApp.config/1
iex> MyApp.config([name: "my_app"])
%{
  author: "Herminio Torres",
  description: "Description",
  name: "my_app"
}
iex> MyApp.config([name: "my_app", description: "Change"])
%{
  author: "Herminio Torres",
  description: "Change",
  name: "my_app"
}

The raised error leads you to which options are required
Keyword lists make the arguments named
Only one function arity is exposed

Awesome!

How to import CSV file to the Database

Herminio Torres — Tue, 19 Dec 2023 12:35:02 +0000

How to import CSV data file to the database and populate the table.

Imagine you have this migration in your application with the following columns:

create table(:users) do
  add :first_name, :string, null: false
  add :last_name, :string, null: false
  add :username, :string, null: false
  add :email, :string, null: false
end

And this would be the CSV file:

First Name,Last Name,Username,Email
John,Doe,john_doe,john@doe.com
Jane,Doe,jane_doe,jane@doe.com
...

And how can I import my CSV file to the users' table on the database?

~$ psql -U user -d database <<USERS
COPY users(first_name, last_name, username, email) FROM '/path/to/users.csv' DELIMITER ',' CSV HEADER;
USERS

After finishing, you will receive an output with COPY 2 the number of copies in your table.

How to take leverage from on_mount to reduce code

Herminio Torres — Tue, 12 Dec 2023 12:00:00 +0000

Phoenix LiveView has implemented some fantastic features, and one of them is the on_mount/1 callback function.

This callback function will run before the mount/3 function in your LiveView.

There are two ways to set the on_mount callback function:

In router using live_session/3.
In your LiveView modules with on_mount macro.

If you need to do something before the mount/3 in all your LiveViews, live_session/3 is likely the best fit. However, if only for a few of them, the on_mount macro will be better for your needs.

on_mount helps reduce repetitive code in your LiveViews. Let's look at an example.

defmodule ExampleWeb.UserHook do
  import Phoenix.LiveView

  def on_mount(:default, _params, %{"current_user" => current_user} = _session, socket) do
    if authorized?(current_user) do
      {:cont, socket}
    else
      {:halt, socket}
    end
  end

  def on_mount(:admin, _params, %{"current_user" => current_user} = _session, socket) do
    if admin?(current_user) do
      {:cont, socket}
    else
      {:halt, socket}
    end
  end
end

The live_session/3 on Router:

live_session :default, on_mount: ExampleWeb.UserHook do
  scope "/", ExampleWeb do
    pipe_through [:browser, :auth]

    live "/", HomeLive, :page
  end
end

The on_mount macro:

defmodule ExampleWeb.HomeLive do
  use ExampleWeb, :live_view

  on_mount {ExampleWeb.UserHook, :admin}

  def mount(_params, _session, socket) do
    # ...
  end
end

What you should know about the live_session macro

Herminio Torres — Tue, 05 Dec 2023 11:00:00 +0000

Imagine you have a few endpoints and would like to group their authorization rules. With live_session/3, can achieve that!

live_session has three options:

session - name of the session
on_mount - callback function
root_layout - apply a different layout to the group

It is important to understand the Security Considerations of live_session, especially for handling authentication and authorization in your LiveView.

In the following example, we use live_session to set a new root_layout only for admin users and authorize admins only in the :admin UserHook

live_session :admins, 
  root_layout: {ExampleWeb.AdminLayoutView, :root},
  on_mount: {ExampleWeb.UserHook, :admin} do
  scope "/", ExampleWeb do
    pipe_through [:browser, :auth]

    live "/admin", HomeLive, :page
  end
end

defmodule ExampleWeb.AdminLayoutView do
  @moduledoc false

  use ExampleWeb, :view

  def render("root.html", assigns) do
    ~H"""
    <!DOCTYPE html>
    <html lang="en">
      <head>
        <title>Admin Layout</title> 
      </head>
      <body>
        <h1>Admin</h1>
        <main>
          <%= @inner_content %>
        </main>
      </body>
    </html>
    """
  end
end

When to use the handle_params callback

Herminio Torres — Tue, 28 Nov 2023 13:40:16 +0000

The handle_params/3 callback helps use the state in the URL to drive the presentation of your LiveView. This is nice because you can share the URL with anyone and see the same LiveView state. handle_params is invoked after mount or during a live navigation event. If your LiveView is changing state based on the URL, handle_params is the right place to assign values to your LiveView, as you will avoid processing both in mount/1 and handle_params/3. To trigger handle_params/3, push_patch/2 can be used server-side, while live_patch/2 will trigger handle_param/3 through a client-side interaction.

For example, imagine we want to use handle_params/3 to implement pagination, filtering, and sorting. Using these two examples, handle_params/3 can handle five different cases of URL state

only pagination /route?page=2&per_page=10
only filtering /route?filter=a
only sorting /route?sort_by=id&sort_order=asc
pagination, filtering, and sorting /route?page=2&per_page=10&filter=sneakers?sort_by=name&sort_order=asc
none specified (use defaults) /route

def handle_params(params, _url, socket) do
  paginate_options = %{page: params["page"], per_page: params["per_page"]}
  filter_options = %{filter: params["filter"]}
  sort_options = %{sort_by: params["sort_by"], sort_order: params["sort_order"]}

  shoes =
    Shoes.list_shoes(
      paginate: paginate_options,
      sort: sort_options,
      filter: filter_options
    )

  {:noreply,
    assign(socket,
      options: Map.merge(paginate_options, sort_options, filter_options),
      shoes: shoes
    )}
end

def handle_params(_params, _url, socket) do
  {:noreply, socket}
end

How to use unique_index wisely to grasp our business logic

Herminio Torres — Wed, 22 Nov 2023 00:20:53 +0000

How do you ensure a unique index when the user tries to get more than one ticket for a paid conference? And the user gets multiple tickets for a free conference?

What are our goals here?

sent paid conference to Ticket.changeset/1 to ensure the status: :paid, create one.
sent free conference to Ticket.changeset/1 to ensure the status: :free, create many.

How can we apply these to our business logic:

create table(:tickets) do
  add :conference_id, references(:conferences), null: false
  add :user_id, references(:users), null: false
  add :status, :string, null: false, default: "free"
end

create unique_index(:tickets, [:conference_id, :user_id, :status], where: "status = 'paid'")

Now, how can we test?

iex> Ticket.changeset(%{conference: %{is_paid: false}, user: %{...}, status: :free}) |> Repo.insert()
[debug] QUERY OK
{:ok, 
  %Ticket%{id: 1, status: :free, conference_id: 1, user_id: 1}
}
iex> Ticket.changeset(%{conference: %{is_paid: false}, user: %{...}, status: :free}) |> Repo.insert()
[debug] QUERY OK
{:ok, 
  %Ticket%{id: 2, status: :free, conference_id: 1, user_id: 1}
}
iex> Ticket.changeset(%{conference: %{is_paid: true}, user: %{...}, status: :paid}) |> Repo.insert()
[debug] QUERY OK
{:ok, 
  %Ticket%{id: 3, status: :paid, conference_id: 2, user_id: 1}
}
iex> Ticket.changeset(%{conference: %{is_paid: true}, user: %{...}, status: :paid}) |> Repo.insert()
[debug] QUERY ERROR
** (Ecto.ConstraintError)

Awesome!

Reference

Ecto.Migration.index/3

Understanding Process Restart Strategies: Transient, Temporary, and Permanent

Herminio Torres — Tue, 19 Sep 2023 23:46:04 +0000

Introduction

In today's building software systems that can gracefully handle failures and maintain uninterrupted operation is crucial. Elixir, a powerful and fault-tolerant programming language, offers a range of strategies for managing processes when they encounter issues. These process restart strategies, including :permanent, :temporary, and :transient, play a pivotal role in ensuring system reliability and resilience. In this guide, we'll explore the concepts and best practices behind these restart strategies, equipping you with the knowledge to design robust and dependable software systems in Elixir.

When do you use which option?

There are three options for :restart:

Use :permanent when:
- The process is critical for the system's overall operation, and its failure would severely impact the system's functionality.
- You want the process to be automatically restarted upon failure to maintain system availability.
- Examples might include database connections, core components, or critical services.
Use :temporary when:
- The process is not essential for the system's continuous operation, and its failure can be tolerated without significant disruption.
- You want to minimize automatic restarts for non-critical processes to avoid excessive resource usage.
- Examples might include non-essential background tasks, loggers, or metrics collectors.
Use :transient when:
- The process is not critical on its own but is part of a group of processes or a subsystem where consistency among processes is important.
- You want to ensure that dependent processes are restarted along with the transient process to maintain overall system integrity.
- Examples might include worker processes in a job processing system or components of a distributed system.

This option allows you to configure the recovery behavior of the GenServer in case of a failure, providing greater control over the system. In summary, the choice of restart strategy depends on the criticality of the process to your system and its dependencies. Careful consideration of these factors helps you design robust and resilient systems that can recover from failures effectively while avoiding unnecessary restarts for non-critical components.

Using the :restart Option

To utilize the restart strategies for a process in Elixir, you typically need to work within a supervision tree, which is a hierarchical structure used to manage and supervise processes. Here's how you can use the different restart strategies (:permanent, :temporary, and :transient):

Creating a Supervisor:
- First, you need to create a supervisor using the Supervisor module. You can use Supervisor.start_link/2 or Supervisor.child_spec/2 to configure the supervisor.
Adding Child Processes:
- You then add child processes (which can include GenServer processes) to the supervisor's supervision tree using the Supervisor.child_spec/2 function. In the child specification, you can specify the :restart strategy.
Defining Restart Strategies:
- In the child specification, you specify the :restart strategy. You can set it to :permanent, :temporary, or :transient, depending on how you want the process to be restarted in case of failures.

Here's a code example of how you might configure a supervisor with different restart strategies:

defmodule Dummy.Application do
  # See https://hexdocs.pm/elixir/Application.html
  # for more information on OTP Applications
  @moduledoc false

  use Application

  @impl true
  def start(_type, _args) do
    children = [
      # Starts a worker by calling: Dummy.Worker.start_link(arg)
      %{
        id: Dummy.Permanent,
        start: {Dummy.Permanent, :start_link, [[]]},
        restart: :permanent,
        type: :worker
      },
      %{
        id: Dummy.Temporary,
        start: {Dummy.Temporary, :start_link, [[]]},
        restart: :temporary,
        type: :worker
      },
      %{
        id: Dummy.Transient,
        start: {Dummy.Transient, :start_link, [[]]},
        restart: :transient,
        type: :worker
      }
    ]

    # See https://hexdocs.pm/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [
      strategy: :one_for_one,
      name: Dummy.Supervisor
    ]

    Supervisor.start_link(children, opts)
  end
end

Dummy.Permanent:

defmodule Dummy.Permanent do
  use GenServer

  def start_link(_) do
    GenServer.start_link(__MODULE__, :ok)
  end

  def init(:ok) do
    {:ok, :initial_state}
  end
end

Dummy.Temporary:

defmodule Dummy.Temporary do
  use GenServer

  def start_link(_) do
    GenServer.start_link(__MODULE__, :ok)
  end

  def init(:ok) do
    {:ok, :initial_state}
  end
end

Dummy.Transient:

defmodule Dummy.Transient do
  use GenServer

  def start_link(_) do
    GenServer.start_link(__MODULE__, :ok)
  end

  def init(:ok) do
    {:ok, :initial_state}
  end
end

Let's start the IEx and get the app running.

$ iex -S mix

If you take a look, we check the count of children in the Dummy.Supervisor. The supervisor started, and the children too. Getting the pid and pipe to Process.exit/2 with the :kill reason. Check the Dummy.Supervisor again. Supervisor children's only rest is Permanent and Transient.

$ iex -S mix
iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 3, workers: 3, supervisors: 0, specs: 3}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, #PID<0.127.0>, :worker, [Dummy.Transient]}
]
iex> pid("0.128.0") |> Process.exit(:kill)
true
iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 2, workers: 2, supervisors: 0, specs: 2}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Transient, #PID<0.127.0>, :worker, [Dummy.Transient]}
]

For this next one, it will be a bit bigger, but bear with me. In this next one, I will play along with the Transient process. If I use any reason to kill the Transient process, he will come back alive again. But if the reason is :shutdown or {:shutdown, term}, the process will not get back alive, and in this situation, we can restart the proccess manually using Supervisor.restart_child/2. And if I kill the temporary and try to restart the process manually, I get a tuple with {:error, :not_found}. One important thing here is that I've been using the child ID.

iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 3, workers: 3, supervisors: 0, specs: 3}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, #PID<0.127.0>, :worker, [Dummy.Transient]}
]
iex> pid("0.127.0") |> Process.exit(:kill)
true
iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 3, workers: 3, supervisors: 0, specs: 3}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, #PID<0.145.0>, :worker, [Dummy.Transient]}
]
iex> pid("0.145.0") |> Process.exit(:normal)
true
iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 3, workers: 3, supervisors: 0, specs: 3}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, #PID<0.145.0>, :worker, [Dummy.Transient]}
]
iex> pid("0.145.0") |> Process.exit(:shutdown)
true
iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 2, workers: 3, supervisors: 0, specs: 3}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, :undefined, :worker, [Dummy.Transient]}
]
iex> Supervisor.restart_child(Dummy.Supervisor, Dummy.Transient)
{:ok, #PID<0.146.0>}
iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 3, workers: 3, supervisors: 0, specs: 3}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, #PID<0.146.0>, :worker, [Dummy.Transient]}
]
iex> pid("0.128.0") |> Process.exit(:shutdown)
true
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Transient, #PID<0.146.0>, :worker, [Dummy.Transient]}
]
iex> Supervisor.restart_child(Dummy.Supervisor, Dummy.Temporary)
{:error, :not_found}

For the last and not least, When I play with the Permanent and try to kill using any kind of reason, the process always gets me back alive.

iex> Supervisor.count_children(Dummy.Supervisor)
%{active: 3, workers: 3, supervisors: 0, specs: 3}
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.129.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, #PID<0.127.0>, :worker, [Dummy.Transient]}
]
iex> pid("0.129.0") |> Process.exit(:shutdown)
true
iex> Supervisor.which_children(Dummy.Supervisor)
[
  {Dummy.Permanent, #PID<0.145.0>, :worker, [Dummy.Permanent]},
  {Dummy.Temporary, #PID<0.128.0>, :worker, [Dummy.Temporary]},
  {Dummy.Transient, #PID<0.127.0>, :worker, [Dummy.Transient]}
]

Conclusion

In conclusion, process restart strategies in Elixir are indispensable tools for crafting software systems that can provide uninterrupted services. By applying strategies like :permanent, :temporary, and :transient. These strategies empower us to build resilient systems that recover gracefully from failures, ensuring a smoother and more reliable experience for end-users. As you continue to explore the world of Elixir and keep these restart strategies in your toolkit.

Reference

Managing Timeouts in GenServer in Elixir: How to Control Waiting Time in Critical Operations

Herminio Torres — Wed, 13 Sep 2023 00:52:40 +0000

Introduction

Elixir's GenServer is a crucial component for building concurrent, fault-tolerant systems. GenServers allow you to create concurrent processes that can maintain internal state and respond to asynchronous messages. One of the most important and versatile options when working with GenServers is :timeout. Here, we'll explore the :timeout option and learn how to effectively manage timeouts in your GenServer-based applications.

What is the `:timeout` Option?

The :timeout option is used when starting a GenServer in Elixir to specify the maximum time a caller is willing to wait for a response from a GenServer function. It defines a time limit for executing an operation within the GenServer. If the GenServer cannot complete the operation within the time specified by the :timeout option, it returns an error.

Why Use a `:timeout`?

Here are some reasons why this option is essential:

Blocking Prevention: One of the main reasons to use a timeout is to prevent blocking in your program. In concurrent systems, it's possible for an operation to take longer than expected due to unexpected conditions, such as a slow external resource or a network issue. A timeout allows you to limit the maximum time an operation can take, preventing your program from getting stuck indefinitely.
Ensuring Responsiveness: When your program is waiting for a response from an external resource or lengthy processing, you don't want the user interface or other system components to become unresponsive. A timeout allows you to return immediately and inform the user that something went wrong, instead of making them wait indefinitely.
Resource Conservation: Limiting the execution time of an operation with a timeout can be important to save system resources. If an operation takes too long, it can result in unnecessary consumption of resources like CPU and memory.

When Use a `:timeout`?

Network Calls: When making network calls to external services, it's a good practice to use a timeout. This protects your system against network failures, such as inaccessible or slow servers.
Lengthy Processing: If you're performing operations that involve lengthy processing, such as intensive calculations, you can use a timeout to ensure that these operations don't monopolize resources for an extended period.
Inter-Process Communication: In concurrent systems that use asynchronous messaging between processes, such as in Elixir's GenServer, a timeout can be useful to set a time limit for receiving a response from a process. This prevents a process from waiting indefinitely for a response that may never arrive.
Time-Critical Operations: In certain cases, such as real-time control systems where operations must be completed within a specific timeframe, using a timeout is critical to ensure the desired system behavior."

Using the :timeout Option

Here's let's define our Module which use a GenServer behaviour:

defmodule MyGenServer do
  use GenServer

  def start_link(_args) do
    GenServer.start_link(__MODULE__, [])
  end

  def init(_args) do
    {:ok, []}
  end

  def handle_call({:slow_operation, _args}, _from, state) do
    current_time = Time.utc_now()
    print_time("handle_call just called", current_time)

    {:reply, do_slow_operation(current_time), state}
  end

  defp do_slow_operation(handle_call_time) do
    :timer.sleep(7000)

    current_time = Time.utc_now()
    time_diff = Time.diff(current_time, handle_call_time)
    print_time("it will printed out after #{time_diff} seconds after handle_call", current_time)
  end

  defp print_time(message, time) do
    %{hour: hour, minute: minute, second: second} = Map.from_struct(time)

    IO.puts("#{message} - #{hour}:#{minute}:#{second}")
  end
end

Here's how you starting a GenServer without :timeout option, and the default value is 5000:

iex> {:ok, pid} = MyGenServer.start_link([])
iex> GenServer.call(pid, {:slow_operation, []})
handle_call just called - 0:35:45
** (exit) exited in: GenServer.call(#PID<0.446.0>, {:slow_operation, []}, 5000)
    ** (EXIT) time out
    (elixir 1.14.2) lib/gen_server.ex:1038: GenServer.call/3
    iex:32: (file)
it will printed out after 7 seconds after handle_call - 0:35:52

Here's how you can use the :timeout option when starting a GenServer:

iex> {:ok, pid} = MyGenServer.start_link([])
iex>> GenServer.call(pid, {:slow_operation, []}, 8000)
handle_call just called - 0:37:12
it will printed out after 7 seconds after handle_call - 0:37:19
:ok

It passes a 8000 as a :timeout value, but it could be any value bigger than my slow_operation/1.

Conclusion

The :timeout option is a powerful tool for controlling the response time of operations in a GenServer in Elixir. Using it wisely helps create more robust and responsive systems, ensuring that your code doesn't get stuck indefinitely and providing a better user experience. Therefore, when working with GenServers in Elixir, don't forget to consider using the :timeout option to optimize your system's behavior.

In summary, you should use a timeout whenever there is a possibility of an operation taking longer than desired and when you want to avoid undesired blocking. However, it's important to carefully choose timeout values to avoid false positives (terminating ongoing operations prematurely) and false negatives (allowing slow operations to continue for too long). The timeout value should be determined based on the nature of the operation and the requirements of your system.

References

Elixir Docs - GenServer Options Timeout

DEV Community: Herminio Torres

Bridging the Gap: Simplifying Live Component Invocation in Phoenix LiveView

Taming data with Ecto.Enum and Ecto.Type

Troubleshooting MacOS Performance: Addressing fseventsd Issues Causing Memory Leaks and Sluggish Performance

Exploring the Data Analysis: From Python Certification to the Elixir Challenge - Mean-Variance-Standard Deviation Calculator

Setup

Challenge

Solution

Test

Execute Test

Using the Keyword module for options

Without options

With Options

How to import CSV file to the Database

How to take leverage from on_mount to reduce code

What you should know about the live_session macro

When to use the handle_params callback

How to use unique_index wisely to grasp our business logic

Reference

Understanding Process Restart Strategies: Transient, Temporary, and Permanent

Introduction

When do you use which option?

Using the :restart Option

Conclusion

Reference

Managing Timeouts in GenServer in Elixir: How to Control Waiting Time in Critical Operations

Introduction

What is the :timeout Option?

Why Use a :timeout?

When Use a :timeout?

Using the :timeout Option

Conclusion

References

What is the `:timeout` Option?

Why Use a `:timeout`?

When Use a `:timeout`?