DEV Community: Willian Frantz

[Boost]

Willian Frantz — Mon, 05 Jan 2026 22:05:44 +0000

Emerson Vieira

Jan 5

React Native em Alta Performance: Expo Modules, C++ e SIMD (ARM NEON)

#expo #reactnative #android #cpp

Comments 2

5 min read

Casamento de Padrões em Elixir

Willian Frantz — Wed, 07 May 2025 18:50:11 +0000

Você sabia que tanto Erlang como Elixir não possuem um operador de atribuição?
Ou seja, o que significa a seguinte expressão abaixo:

message = "Hello World"

Mais conhecido como Pattern Matching, esse mecanismo te permite fazer associações de valores através
da comparação de símbolos entre o lado esquerdo do operador e o lado direito.

Na prática:

iex> hello_world = "Hello World"
iex> hello_world
> "Hello World"

iex> "Hello " <> world = "Hello World"
iex> world
> "World"

Os 2 exemplos acima ilustram o funcionamento do casamento de padrões.
Onde a primeira execução aparenta ser uma simples atribuição, mas a partir da segunda, é possível perceber uma grande diferença conceitual.

No segundo exemplo a runtime irá tentar encontrar o valor "Hello " no valor do lado direito do operador, se esse valor for encontrado(deu match)
o resto do valor será armazenado na variável world.d

Quando essa assertiva não acontece, e o padrão não é encontrado, uma exception é gerada.

iex> "Hellu " <> world = "Hello World"
> ** (MatchError) no match of right hand side value: "Hello World"

Essa é uma das minhas funcionalidades favoritas no ecossistema Erlang/Elixir, e neste texto vou tentar sintetizar um pouco do porquê.

Ex-1. Em Elixir, o casamento de padrões pode ser utilizado em Strings:

# Apenas uma comparação e nada acontece, pois o padrão é encontrado (caso contrário, geraria uma exception)
"Hello World" = "Hello World"

# Assimila o valor "World" à variável world
"Hello " <> world = "Hello World"

# Mesmo resultado do exemplo acima, porém escrito de uma forma diferente. (usando operadores de bitstring)
<<"Hello ", world::binary>> = "Hello World"

# Assimila os primeiros 5 caracteres na variável hello, valida um espaço " ", e joga o resto da string na variável world
<<hello::binary-size(5), " ", world::binary>> = "Hello World"

# Como não existe nenhum padrão a ser encontrado, meio que simula uma atribuição.
hello_world = "Hello World"

É possível usar casamento de padrões com praticamente todos tipos, strings, listas, tuplas, maps, structs...

Ex-2. Testando outros tipos:

# Apenas procura o padrão do lado esquerdo no lado direito do operador, o mesmo com as strings.
[1, 2, 3] = [1, 2, 3]

# Assimila o valor 2 na variável second.
[1, second, 3] = [1, 2, 3]

# Assimila o valor 1 na variável first, e descarta os demais valores. (operadores importantes que usamos para listas `++` e `|`)
[first | _] = [1, 2, 3]

# Ignora apenas o primeiro valor da lista, e assimila os demais na variável rest. (2, 3)
[_ | rest] = [1, 2, 3]

# Simplesmente joga todos os valores da direita do operador na variável list.
list = [1, 2, 3]

E o quão relevante é este tipo de operação no dia-a-dia?
Casamento de padrões pode ser utilizado em praticamente tudo, validação, polimorfia de funções, estruturas de controle, funções de ordem maior.

Ex-3. Em Elixir costumamos trabalhar bastante com o conceito de Tuplas de erro ou sucesso, e isso vale para requests,
comunicação externa, funções impuras, e por ai adiante...

Digamos que a execução de uma função qualquer do nosso código irá retornar uma tupla de sucesso, contendo {status, person}
Podemos tirar vantagem do casamento de padrões nesse cenário para criar uma tomada de decisão no nosso código.

Ilustração:

{:ok, %{name: "Willian"}} = {:ok, %{name: "Willian"}}

# Assimila o valor "Willian" na variável name.
{:ok, %{name: name}} = {:ok, %{name: "Willian"}}

# Assimila todo o map da pessoa na variável person
{:ok, person} = {:ok, %{name: "Willian"}}

# Assimila :ok no status e o map pessoa na variável person
{status, person} = {:ok, %{name: "Willian"}}

# Joga todo o valor da direita do operador na variável tuple_result
tuple_result = {:ok, %{name: "Willian"}}

Criando uma tomada de decisão a partir desse valor:

defmodule Person do
  def print_name(result) do
    case result do
      {:ok, %{name: name}} ->
        IO.puts(name)

      _ ->
        IO.puts("Houve um erro ao processar o resultado")
    end
  end
end

# se executarmos este código passando nosso resultado do exemplo anterior teríamos algo como:
iex> Person.print_name({:ok, %{name: "Willian"}})
> "Willian"

Agora com polimorfismo:

defmodule Person do
  def print_name({:ok, %{name: name}}),
    do: IO.puts(name)

  def print_name(_),
    do: IO.puts("Houve um erro ao processar o resultado")
end

Em funções de ordem maior:

list_results = [
    {:ok, %{name: "Willian"}},
    {:ok, %{name: "Willian"}},
    {:error, "Algo deu ruim"},
    {:ok, %{name: "Willian"}},
    {:ok, %{name: "Willian"}},
    {:ok, %{name: "Willian"}},
    {:error, "Algo deu ruim"}
]

res = Enum.filter(list_results, fn
  {:ok, %{name: name}} -> true
  {:error, _reason} -> false
end)

No caso acima, iremos filtrar da lista de resultados somente as tuplas de sucesso, e ignorar as que tiveram erro.

Concluindo, essa funcionalidade me permiti flexibilidade na hora de manipular dados e basicamente escrever toda estrutura do meu código,
tratamento de erros, estruturas condicionais, polimorfismo, e muito mais que não consigo nem lembrar direito.

Consumindo GraphQL com Elixir?

Willian Frantz — Thu, 02 Jun 2022 16:41:55 +0000

Hoje em dia é muito comum ver um serviço backend em Elixir servindo uma API com endpoint GraphQL usando uma biblioteca chamada Absinthe.

Mas você já se perguntou como funcionaria isso se a nossa necessidade fosse consumir um Endpoint GraphQL já existente em outro serviço externo?

Digamos que você precise ingerir e processar dados para renderizar isso no seu frontend com Elixir (usando LiveView, etc).

A ideia deste texto é mostrar o quão simples é consumir dados de um endpoint GraphQL usando apenas requests HTTP.

Vamos la!

O que é GraphQL?

Grosseiramente falando, é uma linguagem de busca/manipulação de dados e também uma ferramenta para criação de APIs.

Uma implementação de GraphQL te permite ter os dois lados da moeda:

Criar um serviço backend de CRUD (Create, Read, Update e Delete) para recursos.
Consumir dados deste serviço a partir de um frontend com requisições HTTP ou utilizando uma biblioteca de cliente apropriado para o mesmo.

E diferente de uma implementação REST padrão, onde você teria um endpoint para cada ação do seu CRUD/serviço. Aqui você irá utilizar um único endpoint, e através do payload (corpo da requisição) você indicará o que você precisa, seja busca ou manipulação de dados, e irá elencar quais dados de um determinado modelo.

Como isso funciona na prática? Usando como exemplo o endpoint disponibilizado pelo GitHub, irei requisitar dados do repositório oficial do Elixir.

Para ter uma noção mais apurada sobre como funciona o endpoint do github, recomendo este link.

Irei usar a seguinte Query para buscar informações básicas sobre o Repo:

query {
  repository(owner: "elixir-lang", name: "elixir") {
    name,
    pushedAt,
    createdAt,
    owner { login },
    latestRelease { id },
    defaultBranchRef { name }
  }
}

Note que eu determino o primeiro termo query para indicar que estou buscando dados, e logo após, repository para indicar que os dados que estou buscando são sobre repositórios cujo owner se chama elixir-lang e o nome seja elixir.
Como resposta a isso, receberei os mesmos dados name, pushedAt, createdAt, owner.login, latestRelease.id, defaultBranchRef.name preenchidos.

Vale ressaltar que no graphql eu determino exatamente o que eu estou buscando, e a resposta será praticamente espelhada nessa requisição.

Para simular essa query estarei usando o cURL, mas caso você queira testar de outra maneira, existe um cliente próprio para isso chamado GraphiQL.

cURL:

curl -X POST "https://api.github.com/graphql" \
-H "Authorization: Bearer SEU_TOKEN_AQUI" \
-d '{"query": "query { repository(owner: \"elixir-lang\", name: \"elixir\") { name, pushedAt, createdAt, owner{login}, latestRelease{id}, defaultBranchRef{name} } }"}'

(Substitua a parte "SEU_TOKEN_AQUI", pelo seu token pessoal para testes)

Obtemos a seguinte resposta:

{
  "data": {
    "repository": {
      "name": "elixir",
      "pushedAt": "2022-06-01T15:57:31Z",
      "createdAt": "2011-01-09T08:43:57Z",
      "owner": {
        "login":  "elixir-lang"
      },
      "latestRelease": {
        "id":"RE_kwDOABLXGs4DzeaA"
      },
      "defaultBranchRef": {
        "name":"main"
      }
    }
  }
}

A resposta irá conter exatamente o que pedimos na requisição.

Resumo: Com apenas um endpoint e um payload flexível, eu consigo dizer para o serviço backend oque eu preciso, e ele me responde somente o necessário.

Para mais informações sobre GraphQL, eu recomendo este link.

Como consumir um Endpoint com Elixir?

Como vimos anteriormente, é possível consumir um endpoint apenas fazendo chamadas HTTP para o mesmo.

Seguindo esta ideia, vou simular a requisição acima com Elixir, utilizando as seguintes bibliotecas:

httpoison:1.8 (Cliente HTTP, para requisições)
jason:1.3 (Conversor de JSON)

defmodule Github.GraphQL do
  @moduledoc """
  Módulo responsável por se comunicar com o endpoint GraphQL do Github.
  """

  @endpoint ~s(https://api.github.com/graphql)
  @token ~s(SEU_TOKEN_AQUI)

  @doc """
  Busca informações básicas de um determinado repositório.

  ## Exemplos

      iex> repo_info("elixir-lang", "elixir")
      %{
        "data" => %{
          "repository" => %{
            "createdAt" => "2011-01-09T08:43:57Z",
            "defaultBranchRef" => %{"name" => "main"},
            "latestRelease" => %{"id" => "RE_kwDOABLXGs4DzeaA"},
            "name" => "elixir",
            "owner" => %{"login" => "elixir-lang"},
            "pushedAt" => "2022-06-01T15:57:31Z"
          }
        }
      }
  """
  @spec repo_info(String.t(), String.t()) :: map()
  def repo_info(owner, repo) do
    payload = %{
      variables: %{owner: owner, name: repo},
      query: ~S"""
      query GetRepoInfo($owner: String!, $name: String!) {
        repository(owner: $owner, name: $name){
          name,
          pushedAt,
          createdAt,
          owner {
            login
          },
          latestRelease {
            id
          },
          defaultBranchRef {
            name
          }
        }
      }
      """
    } |> Jason.encode!()

    with {:ok, %HTTPoison.Response{body: body, status_code: 200}} <- HTTPoison.post(@endpoint, payload, headers()) do
      Jason.decode!(body)
    end
  end

  defp headers do
    [
      {"Authorization", "Bearer #{@token}"},
      {"Content-Type", "application/json"}
    ]
  end
end

Perceba como no payload eu criei um map com dois valores (variables e query). Neste caso, por motivos de organização, optei por isolar as variáveis name e owner do resto da query, para não precisar fazer interpolação na String. (Isto é algo próprio do GraphQL, onde o campo variables é opcional).

A execução seria:

iex> repo_info("elixir-lang", "elixir")
%{
  "data" => %{
    "repository" => %{
      "createdAt" => "2011-01-09T08:43:57Z",
      "defaultBranchRef" => %{"name" => "main"},
      "latestRelease" => %{"id" => "RE_kwDOABLXGs4DzeaA"},
      "name" => "elixir",
      "owner" => %{"login" => "elixir-lang"},
      "pushedAt" => "2022-06-01T15:57:31Z"
    }
  }
}

Por padrão um endpoint GraphQL recebe as seguintes informações via payload:

{
  "query": "query a ser executada"
  "variables": {"variavel": "valor"}
  "operationName": "NomeDaOperação"
}

E a resposta é sempre a mesma, contendo uma chave data com os dados requisitados, ou uma chave errors contendo os possíveis problemas na construção da sua query.

Conclusão

Consumir um endpoint GraphQL pode ser tão simples quanto consumir qualquer outro serviço utilizando o seu cliente HTTP de preferência.

E ainda é possível criar todo um padrão para consumo GraphQL com Elixir, usando behaviours e contextos para envelopar o código, pattern matching para tratamento de erros nas respostas, organização das variáveis de ambiente/aplicação, e por ai vai...

Isso te interessou? foi útil? Deixa nos comentários para eu ficar por dentro!

Abraços!

💚💜 Elixir é amor, Erlang é vida! 💜💚

5 curious facts about Elixir

Willian Frantz — Thu, 14 Oct 2021 12:27:58 +0000

Elixir is a functional programming language that runs on the BEAM virtual machine, itself used to implement Erlang. Elixir extends Erlang and provides interoperability between both languages. Its syntax is easy to understand and its tools help to standardize code so it's easier to move from one project to the next.

My name is Willian Frantz and I've been an Elixir Alchemist since 2017. I actively contribute to the Brazilian programming community by writing blog posts, speaking at events, and contributing to open-source libraries.

Despite being used by companies such as Pinterest, Slack, and Discord, Elixir remains a niche programming language. That's why I want to give you 5 curious facts about Elixir. Hopefully, they will encourage you to give the Elixir programming language a look.

1. Functional, but Dynamic too

Elixir is a functional language, but it also allows you to rebind a variable. This is only possible because of the pattern matching operator =. For example:

iex> a = "Something"
iex> a = "Else"
iex> IO.puts(a)
"Else"

2. There's No Assign Operator

That's right. Elixir has no assign operator. Instead, it uses = as its main pattern matching function. Every time you use =, you're pattern matching. For example:

iex> a = ["Something", "Else"]
iex> IO.puts(a)
"SomethingElse"

iex> ["Something", a] = ["Something", "Else"]
iex> IO.puts(a)
"Else"

iex> %{name: name} = %{name: "Willian"}
iex> IO.puts(name)
"Willian"

Pattern matching is an amazing functionality in Elixir. You can use it to write complex business logic and decision-making capabilities into your code. For example, let's use it to create function polymorphism:

def hello("") do
  raise "Empty string provided"
end

def hello(name) do
  IO.puts("Hello World, #{name}!")
end

In this example, if we call the hello/1 function (with /1 indicating the number of arguments it expects) and give it an empty string as its main argument, it will raise an exception with the message "Empty string provided". Otherwise, it will print "Hello World, {name}".

Another way to create function polymorphism is by using bodyguards. Elixir has some default functions called guards that you can use to control structures (like case/do) or apply to a function scope. For example:

def hello(name) when is_binary(name) do
  IO.puts("Hello World, #{name}!")
end

def hello(var) do
  raise "Expected a String, received: #{var}"
end

We added a guard called is_binary/1 to our function, which checks if the name is actually a string. If it fails to validate the string, it will raise an exception that says "Expected a String, received: {var}".

3. Elixir Goes Meta

Here's a mind-blowing fact: 92% of Elixir's source code is written in Elixir. That's why dealing with constructs is so flexible in Elixir. The programming language is meta: it allows you to write code that writes code, so you can, for example, extend your Elixir program with macros.

Let's use an Elixir pipe operator to solve chainable calls:

# without pipe operator
Enum.frequencies(String.split("Repeated Chars on String", "", trim: true))

# result:
%{
  " " => 3,
  "C" => 1,
  "R" => 1,
  "S" => 1,
  "a" => 2,
  "d" => 1,
  "e" => 3,
  "g" => 1,
  "h" => 1,
  "i" => 1,
  "n" => 2,
  "o" => 1,
  "p" => 1,
  "r" => 2,
  "s" => 1,
  "t" => 2
}

# Same code with pipe operator
"Repeated Chars on String"
|> String.split("", trim: true)
|> Enum.frequencies()

The pipe operator breaks chainable calls into a sequential, readable list of code. You could read this as:

I have a string "Repeated Chars on String"
I want to split that string by character and trim it
I want the frequencies of the generated list
We can actually pipe into control structures:

# without pipe operator
if Enum.sum(1..10) == 55 do
  IO.puts("1..10 sum = 55")
end

# with pipe operator
1..10
|> Enum.sum()
|> Kernel.==(55)
|> if do
  IO.puts("1..10 sum = 55")
end

While I wouldn't recommend to use a pipe operator in this case, it's a good demonstration of how flexible Elixir can be.

4. How Elixir Deals with Strings

Imagine we have both a string "Hey I am a String" and a charlist 'Hey I am a Charlist'. We can cast either whenever we need:

iex> "to Charlist" |> to_charlist()
'to Charlist'

iex> 'to String' |> to_string()
"to String"

We can also interpolate or concatenate strings:

# Interpolation
iex> a = "some"
iex> b = "thing"
iex> "String: #{a}#{b}"
"String: something"

# Concatenation
iex> "String: " <> "something"
"String: something"

Since Elixir deals with strings as sequences of bytes, we can also use binary operations to create strings:

iex> <<"String: ", "some", "thing">>
"String: something"

Or combine binaries with pattern matching:

iex> <<"String: ", rest::binary>> = "String: something"
iex> rest
"something"

5. There Are No Loops

Elixir doesn't have loops. Instead, it uses list comprehensions, recursion, and higher-order functions to iterate over a collection of items. Let's go over each in order.

Here's an example of how you can use list comprehensions to generate a list of squared numbers:

iex> for n <- [1, 2, 3, 4], do: n * n
[1, 4, 9, 16]

Elixir handles recursion pretty well too. Because recursive calls are optimized, they use almost the same amount of space as an imperative loop. Take this programmed factorial, for example:

defmodule Fact do
  def call(1), do: 1
  def call(a), do: call(a - 1) * a
end

iex> Fact.call(5)
120

We can recursively calculate the factorial of a number without having any call-stack issues. This works even with a much bigger number:

iex> Fact.call(50)
30414093201713378043612608166064768844377641568960512000000000000

Last but not least, we have higher-order functions, a set of functions that take another function as input (e.g. map, reduce, filter, etc). Let's say we want to find all the even numbers in a list.

iex> Enum.filter(1..20, &Integer.is_even/1)
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

In this example, we used:

Enum.filter/2 to filter our collection.
1..20 to generate a list of numbers from 1 to 20.
A capture operator & into Integer.is_even/1 as the function that the filter uses.

In Conclusion

I hope I've captured your interest with these 5 curious facts about Elixir. In my opinion, Elixir has a few unique features that make it stand out from other languages. If you'd like to know more, check out the following Elixir resources:

Mas e os loops em Elixir?

Willian Frantz — Mon, 23 Aug 2021 21:54:27 +0000

Se você está vindo de uma linguagem de paradigma imperativo, orientada a objetos, muito provavelmente você vai esbarrar nessa pergunta do título.

Pois bem, Elixir não possui esse termo em seu vocabulário. Apesar de ser possível iterar sobre uma lista de elementos utilizando o for:

iex> for n <- [1, 2, 3, 4], do: n * n
[1, 4, 9, 16]

Isso não significa que o Elixir possui loops, esse for nada mais é do que uma chamada nativa ao List Comprehensions do Erlang.

Curioso né? Como fazer para lidar com uma coleção de itens então?

Há 2 maneiras de trabalhar com este tipo de problema, sendo elas:

High Order Functions (map, reduce, filter, find, etc...)
Recursividade

High Order Functions

É muito comum se deparar com uma situação onde você tem uma lista de elementos e precisa manipular os dados dela.

E para isso podemos utilizar funções como map, reduce, filter, etc.

Digamos que você precise multiplicar todos os elementos da sua lista por 2, isso deveria ser um problema trivial, certo?

A implementação desse problema em js utilizando uma estrutura de repetição (loop) seria mais ou menos assim:

const list = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
for (let i = 0; i < list.length; i++) {
  list[i] = list[i] * 2;
}

> list
> [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

Em Elixir é possível resolver isso com map/2:

iex> list = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
iex> sum = fn x -> x * 2 end
iex> Enum.map(list, sum)
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

Comparando os exemplos acima, diferente da estrutura de repetição, com o map/2 não é necessário definir nada além da fórmula para mapear os dados da minha lista, onde a fórmula é x -> x * 2.

O próprio map/2 faz o resto do trabalho aplicando a fórmula pra cada elemento da nossa lista, e gerando uma nova lista ao final da execução.

Segue o mesmo conceito para as demais funções, como:

map/2 manipula os elementos e gera uma nova lista
filter/2 filtra os elementos e gera uma nova lista
reduce/2 manipula os elementos acumulando seus resultados anteriores

Existem diversos tipos de High Order Functions disponíveis no Elixir, feitas para facilitar a sua vida na hora de resolver problemas sejam eles triviais ou não.

Recursividade

Mesmo que você seja uma pessoa de linguagens imperativas, o termo recursividade ainda é algo familiar!

E o que é recursividade? É uma forma de iterar sob listas (ou não), onde a função chama ela própria até atingir uma condição de parada.

Um exemplo muito conhecido sobre recursividade, é o cálculo fatorial de um número, onde 4! = 4 x 3 x 2 x 1 = 24

Destrinchando esse cálculo, teríamos algo semelhante a:

4! = 3! * 4
   = 2! * 3
   = 1! * 2
   = 1

Considerando o exemplo acima, a condição de parada para essa execução é o valor 1. Quando a função fatorial receber como argumento o valor 1, ela deverá retornar 1 e as outras execuções devem se basear neste valor, exemplo:

4! = (6) * 4 = 24
   = (2) * 3
   = (1) * 2
   = 1

Em parênteses: resultado da chamada fatorial anterior.

A implementação em JS:

fact = (val) => {
  if (val == 1) return 1;

  return fact(val - 1) * val;
};

Essa mesma função em Elixir fica assim:

def fact(1), do: 1
def fact(a), do: fact(a - 1) * a

Nota-se que na chamada recursiva, a função fact/1 chama a si mesma passando o argumento - 1, e quando essa função é chamada com o valor 1, ela retorna somente o valor 1 e encerra sua execução em cadeia.

Vamos analisar mais de perto essa chamada do fact/1:

# Considere que estamos chamando fatorial com o argumento 4 (4!)

fact(4) -> fact(4 - 1) * 4 # Esse será o retorno
# Ele estará chamando fact(3) e multiplicando por 4.
# E assim sucessivamente...

fact(3) -> fact(3 - 1) * 3
fact(2) -> fact(2 - 1) * 2
fact(1) -> 1

# Essa abordagem gera uma cadeia de chamadas que precisam ser resolvidas.
# Quando a chamada em cadeia chega na nossa condição de parada (1)
# O processador começa a desencadear essas chamadas que empilhamos.
# Seguindo assim:

fact(1) -> 1
fact(2) -> (1) * 2 -> 2
fact(3) -> (2) * 3 -> 6
fact(4) -> (6) * 4 -> 24

Implementar uma função fatorial utilizando recursividade é bem simples, né? Mas se formos considerar a explicação que acabamos de ver, isso pode se tornar um problema?

Imagine que temos uma função que precisará iterar milhares de vezes para resolver um determinado problema, precisaremos empilhar várias chamadas não-resolvidas na nossa pilha de chamadas, e isso poderá estourar o limite da pilha.

Para esse problema em específico, há uma solução chamada Tail Call Optimization (ou TCO). Com TCO é possível eliminar essas chamadas não-resolvidas que uma função recursiva costuma criar.

O pulo do gato quando aplicamos Tail Call Optimization em uma função recursiva é que essa função saiba o valor processado em todas as suas chamadas, sendo assim, ela não depende do desencadeamento para encontrar o valor final de sua execução.

E como podemos fazer isso? Segue o exemplo de uma chamada sem TCO:

# nossa condição de parada
def fact(1), do: 1

# função fatorial recursiva
def fact(val), do: fact(val - 1) * val

com TCO:

def fact(val), do: fact(val - 1, val)

# nossa condição de parada
defp fact(1, res), do: res

# função fatorial recursiva
defp fact(val, res), do: fact(val - 1, res * val)

A grande diferença, é que na função fatorial com TCO, ela sabe exatamente o valor da sua execução.

fact(4) -> fact(4 - 1, 4)
fact(3, 4) -> fact(3 - 1, (4 * 3)) -> fact(2, 12)
fact(2, 12) -> fact(2 - 1, (12 * 2)) -> fact(1, 24)
fact(1, 24) -> 24

Portanto, quando a nossa função chega na sua condição de parada, não é necessário desencadear todas as chamadas anteriores e seus respectivos cálculos. Ela só precisa retornar seu valor final (24) para a função que originou a sua chamada fact(4).

Fato curioso: Por padrão, Elixir/Erlang implementam Tail Call Optimization, por isso a utilização de recursividade é algo muito comum e encorajada! Inclusive as High Order Functions são implementadas através de recursividade, no final das contas.

Conclusão

Elixir é amor, Erlang é vida.

Behaviours em Elixir

Willian Frantz — Tue, 01 Jun 2021 01:42:39 +0000

Assim como Protocols, Behaviours também são uma forma de manter um padrão de interface/herança e até mesmo polimorfismo no Elixir.

Vale lembrar que Elixir é uma linguagem de programação funcional, portanto, não é o nosso forte o conceito de objeto, classe e métodos. No final, sempre estaremos falando sobre módulos e funções!

Então de que me serve possuir uma abstração para criar interfaces em uma tecnologia como esta?

Cenário

Imaginem que vamos desenvolver uma aplicação onde a pessoa insere seus dados para consultar todos seus cartões de crédito, verificar se as faturas estão em dia, e inclusive gerar possíveis estratégias financeiras, etc...

Para isso precisamos criar uma API REST que irá consultar de diversas fontes de cartões para validar os dados e processar as respostas finais.

Você consegue identificar um padrão nisso? Se precisamos consultar mais de uma API externa para reunir os dados para a resposta final, isso significa que nosso código terá muitos módulos que serão correspondentes a provedores diferentes (ex: Itaú, Nubank, etc...)

Problema

Como iremos mapear todos esses módulos de provedores que vamos criar dentro do nosso sistema então? Como garantir que eles precisam ter uma execução semelhante, retornando os dados processados da mesma forma?

Tendo em vista que as APIs externas podem ser distintas, possuir dados diferentes e respostas diferentes, isso pode se tornar um problema e pode nos levar a criar códigos aleatórios para solucionar cada tipo de API de uma forma desnecessária.

Behaviours

Com behaviours conseguimos criar um padrão comportamental, definindo uma assinatura pré-exigida pelo módulo, garantindo que todos os módulos subsequentes que irão se especializar naquela API precisarão implementar aqueles requisitos.

Em outras palavras, considere sendo essa a nossa interface de acesso à APIs externas:

defmodule Bank.API do
  @moduledoc """
  Este módulo é responsável por definir uma interface 
  padrão para os demais módulos de acesso ao 
  Banco implementarem.
  """

  @type params() :: map()
  @type response() :: {:ok, map()} | {:error, String.t()}

  @doc """
  Este método irá acessar a base externa e
  retornar os dados bancários da pessoa usuária
  """
  @callback call(params()) :: response()
end

Ignorando os moduledocs e typespecs do nosso módulo, nos resta essa @callback, que é exatamente o comando utilizado para definir as funções que deverão ser implementadas pelo módulo que pretende se especializar nessa API.

Perceba o quão genérico nossa interface ficou, ela só da a entender que é uma API de Banco, com uma função de chamada. Em momento algum foi especificado qual o tipo de banco, ou como essa chamada será feita (via: API, gRPC, SOAP, etc...), isso será total responsabilidade de quem for implementar essa interface.

Agora com nosso behaviour bem definido, podemos seguir para a implementação do primeiro Client que iremos utilizar em nossa aplicação para consultar os dados:

defmodule Bank.Nubank do
  @moduledoc """
  Módulo que implementa a requisição para a API do Nubank.
  """

  @behaviour Bank.API

  @impl true
  def call(%{user_id: id}) do
    id
    |> nubank_url()
    |> HTTPoison.get()
    |> case do
      {:ok, %{status_code: 200, body: response}} ->
        {:ok, response}

      {:error, reason} ->
        {:error, reason}
    end
  end

  defp nubank_url(id), do:
      Application.get_env(:my_app, :nubank)[:url] <> "/user/#{id}"
end

(a requisição acima é meramente ilustrativa 😅)

O comando @behaviour Bank.API descreve que nosso módulo Nubank irá se especializar no Bank.API, logo, ele deverá implementar a seguinte função: call/1.

Com isto, temos nosso primeiro provedor implementado, yaay 🚀!

Conclusão

Gosto de dizer que estamos definindo padrões comportamentais, com isso, quando vemos que um módulo específico implementa um Behaviour, já dá para ter uma ideia de quais funções ele roda, qual o seu propósito, como ele deve ser implementado em termos de input e output.

Esse tipo de padronização ajuda a escalar nosso código, diminuir a curva de aprendizagem para novas pessoas desenvolvedoras e inclusive é uma ótima ferramenta para auto-documentar nosso código, deixa tudo mais descritivo e explícito!

E você, o que acha de behaviours? Gostaria de complementar, adicionar ou remover alguma informações deste tópico?

A salada de frutas dos modelos de dados

Willian Frantz — Tue, 11 May 2021 21:46:46 +0000

Você sabia que existem diversos modelos de dados além do padrão relacional (ex PostgreSQL) e o baseado em documentos (ex MongoDB)?

Acredito que esse detalhe passe despercebido por muitas pessoas desenvolvedoras, não que isso seja um problema. Na maioria dos casos é possível atender a sua necessidade com Postgres, e as vezes utilizaremos modelos diferentes de forma implícita, como em uma ferramenta de Cache.

Portanto, gostaria de enfatizar que estou escrevendo este texto apenas para saciar a curiosidade de vocês, e meu próprio interesse por modelos de dados. 😅

Vamos começar dissecando alguns dos diferentes modelos existentes? Na nossa lista temos:

armazenamento por chave-valor
armazenamento em triplas
armazenamento em documentos
armazenamento relacional
armazenamento em grafos

Modelo Chave-Valor

Um dos modelos mais simples de armazenamento de dados, ele utiliza apenas chave=valor, é um dado altamente desacoplado e sem conexões, não possui relacionamentos.

Se fôssemos representar esse modelo com um Map em Elixir seria algo mais ou menos assim:

%{
  key: "value"
}

Ex:

%{
  name: "John Doe",
  age: 30
}

O que representaria uma estrutura map in-memory, semelhante a um JSON.

Este modelo é amplamente utilizado em ferramentas de Cache hoje em dia, como por exemplo: Redis e Memcached. Digamos que você possui um dado que é usado com frequência pela sua aplicação, e esse dado não costuma sofrer alteração. Nesses cenários específicos nós aplicamos um cache para garantir que esse dado fique armazenado de forma simples e rápida de buscar, assim evitamos chamadas desnecessárias ao banco de dados (round trips).

Modelo de triplas

Também é um modelo extremamente simples. Possui uma forma homogênea de armazenar o dado, onde todas entradas são estruturas da seguinte forma: (sujeito, predicado, objeto)

Podemos ter uma entrada que represente a nossa idade, nosso nome, etc.
Por exemplo:

(john_doe, idade, 30)
(john_doe, nome, "John Doe")
(john_doe, gosta, "macarronada")

No final das contas, a ideia por trás desse esquema é que possamos representar uma sentença, como por exemplo "John Doe tem 30" ou "John Doe gosta de maçãs".

O próprio triple store ou também conhecido como RDF, utiliza queries semânticas através do SPARQL (Protocol and RDF Query Language) para conseguir manipular ou buscar suas triplas.

Normalmente uma Query de busca se baseia no predicado, ex com SPARQL:

SELECT ?person :nome "John Doe"

Aqui buscamos a pessoa cujo nome é John Doe. É possível ter relacionamentos neste modelo, porém, sempre seguindo o padrão proposto de sujeito-predicado-objeto.

Curiosidade: Este esquema é muito utilizado em uma linguagem de programação declarativa, que também serve como linguagem de Query chamada Datalog, ele cria entradas com um padrão bem semelhante, seguindo o formato: predicado(sujeito, objeto)

idade(john_doe, 30)
nome(john_doe, "John Doe")
gosta(john_doe, "maçãs")

E inclusive, o Datomic é uma implementação do Datalog. O Datomic, para quem não conhece, é um banco de dados distribuído, ACID, que é muito utilizado com o Clojure na JVM. (Inclusive é o banco que o Nubank usa!)

O modelo de triplas ou RDF, também é mencionado em artigos sobre Semantic Web, que prega a transformação da Internet num lugar onde a camada semântica seja mais acessível.

Modelo de Documentos

Aqui já percebemos uma forma mais rebuscada de armazenar o nosso dado; normalmente os bancos baseados em documentos trabalham com collections e documents (que são objetos JSON-like).

Esse padrão de armazenamento é muito conhecido por se assemelhar a um objeto JSON.
Exemplo de um objeto:

{
  "name": "notebook",
  "qty": 50,
  "rating": [ { "score": 8 }, { "score": 9 } ],
  "size": { "height": 11, "width": 8.5, "unit": "in" },
  "status": "A",
  "tags": [ "college-ruled", "perforated"]
}

(ex retirado da documentação do próprio MongoDB)

A partir daqui já começamos a enxergar dados que se conectam, que se relacionam diretamente. Como podemos ver no exemplo acima: temos um notebook com 50 unidades em estoque, onde as avaliações impostas a ele foram nota 8 e nota 9, fora demais detalhes sobre tamanho, status, tags, etc.

É interessante frisar aqui, que apesar desses dados se relacionarem, estamos falando de um documento (muito semelhante a uma estrutura JSON), portanto, este documento é salvo exatamente desta forma, com todas as relações e conexões no mesmo objeto, é como se estivéssemos compactando um JSON numa String. Pelo dado ser salvo todo junto, é muito mais simples buscar esse dado do banco, tendo em vista que ele só precisa carregar o que foi salvo no documento. Porém por outro lado, por mais que você só deseje acessar uma pequena parte do documento (ex dados como name e qty), todo o documento precisa ser carregado da mesma forma.

Um banco muito utilizado atualmente que implementa este formato de modelo baseado em documentos é o MongoDB!

Modelo Relacional

Se no modelo anterior falamos um pouco sobre relacionamentos entre dados, agora vamos entrar com força nesse assunto. O modelo relacional é conhecido por nos permitir mapear o mundo usando esquemas e relações.

Nele não falamos mais apenas sobre chave=valor, muito menos sobre documentos. Nele utilizamos os termos banco, esquema, tabela, relacionamentos, e por aí vai...

Digamos que estamos mapeando estruturas para o site do nosso restaurante, teríamos algo semelhante a:

Tabela Menu

id	name	hour	status
1	Almoço	11h~13h	on
2	Janta	18h~22h	on
3	Sobremesa	all-day	on

Tabela Prato

id	name	price	menu_id
1	Strognoff	R$49	1
2	Sopa	R$35	2
3	Sorvete	R$12	3
4	Mousse	R$20	3

Olha que interessante, acabamos de ilustrar 2 tabelas que serão utilizadas para representar os dados do nosso restaurante, nele teremos menus que serão divididos entre [Almoço: 1, Janta: 2, Sobremesa: 3], e definimos também 3 pratos diferentes para cada um dos menus, sendo eles [Strognoff: Almoço, Sopa: Janta, Sorvete: Sobremesa]

Apesar desses dados estarem separados por tabelas, eles estão relacionados pelo menu_id, o que chamamos de foreign key em bancos relacionais. Com isso, conseguimos afirmar que um prato pertence a um Menu, e um Menu pode possuir diversos pratos diferentes! Isso simboliza um relacionamento 1..n de menus para pratos.

E conseguimos validar/testar esses relacionamentos através de um join feito por uma linguagem de Query chamada SQL (Structured Query Language).

Ex:

SELECT * FROM menus m
INNER JOIN pratos p ON p.menu_id=m.id
WHERE m.name = 'Almoço'

Traduzindo o resultado disso para um objeto JSON, teremos algo mais ou menos assim:

{
  'name': 'Almoço',
  'hour': '11h~13h',
  'status': 'on',
  'pratos': [
    {
      'name': 'Strognoff',
      'price': 'R$49'
    }
  ]
}

A coisa tá ficando mais abstrata e complexa comparada ao primeiro modelo discutido aqui, não é mesmo? Mas imaginem a infinidade de coisas que podemos modelar utilizando um banco relacional...

Ele nos dá um universo de opções, como por exemplo:

mapear os nossos dados utilizando diferentes tipos (entre valores inteiros, string, até estruturas JSON)
buscar esses dados de forma fragmentada (somente alguns dados de uma tabela)
buscar dados de 2 ou mais tabelas que se relacionam, através de joins
criar indexes para os dados que mais se relacionam, isso faz com que o banco consiga encontrar aqueles dados de forma mais fácil, isso pode melhorar a performance de nossas buscas (dependendo do tamanho do seu banco)
criar views ou views materializadas, que são bem semelhantes a uma tabela, porém com dados modelados de uma forma mais madura para que a aplicação final possa utilizar isso em funcionalidades específicas.

Além disso, bancos de dados relacionais são muito conhecidos por serem ACID.

Atômico - Garante que cada transação é tratada como uma unidade separada, e que ou roda tudo com sucesso, ou não roda nada e nenhuma alteração é aplicada ao estado do banco.
Consistente - Garante que o banco de dados não será corrompido de forma alguma. Sem falhas, seguindo as regras, constraints, cascades e triggers definidos. Mantendo sempre um estado consistente.
Isolado - A ideia de grandes bancos relacionais é garantir que as execuções possam rodar de forma concorrente ao máximo possível, ter um ambiente isolado ajuda no controle de concorrência, pois estamos sempre garantindo que o estado do banco estará da mesma forma que ele estaria se as execuções estivessem sendo feitas de forma sequencial.
Durabilidade - Garante que seus dados estarão salvos independente de uma falha na aplicação, queda de energia ou qualquer outra coisa que possa afetar o processo do banco.

Um bom exemplo de um banco de dados relacional que é muito utilizado atualmente é o Postgres!

Modelo de Grafos

Ué, grafos? Sim, aqueles grafos que você provavelmente viu na faculdade! Bolinha e tracinho pra todo lado, onde as bolinhas representam os nós e os tracinhos as arestas que conectam os nós.

Mas o que isso tem a ver com modelo de dados? Bom, isso significa um modelo de dados altamente conectado, que se relacionam múltiplas vezes.

Neste modelo podemos ter nós com propriedades específicas, como por exemplo, digamos que o nó representa uma pessoa, o mesmo nó pode ter as seguintes propriedades:

nome
idade
altura
peso

E esse nó pode se relacionar com outro nó, através de uma aresta, que indica um relacionamento.

Por sua vez, relacionamentos podem ser indicados de duas maneiras, sendo elas: [saída: outgoing, entrada: incoming]. E esse mesmo relacionamento pode possuir uma propriedade que esclarece qual o propósito do relacionamento.

Ex:

Nesse cenário, temos um nó que representa um usuário chamado John Doe, ele se relaciona com outro nó que representa um país chamado Canadá, e o propósito do relacionamento é indicar que John Doe mora/reside no Canadá.

Representando isso usando Cypher (Query Language do Neo4j):

(u:User {name: 'John Doe'}),
(c:Country {name: 'Canadá'}),
(u)-[:LIVES_IN]->(c)

Você não precisa necessariamente possuir um esquema pré-definido para poder criar nós e relacionamentos, eles podem ser criados com as propriedades e propósitos que melhor satisfazer a sua necessidade.

Um bom exemplo de banco de dados atual que utiliza esse modelo é o Neo4j.

Conclusão

O que podemos deduzir após olhar esses modelos? Claramente eles possuem uma certa afinidade, já que todos modelam dados para serem armazenados. Porém, eles são extremamente diferentes na modelagem, abordagens de relacionamentos, armazenamento, etc. E isso impacta diretamente no propósito deles.

Pode ser que um dia você esbarre na necessidade de utilizar um banco key-value como Cache para a sua aplicação, um banco de documentos como uma estratégia de armazenar dados fragmentados que se relacionam mas que não possuem conexões externas. Ou até mesmo um banco de grafos para conseguir modelar a sua solução, tendo em vista que seus dados possuem muitos relacionamentos many-to-many.

Se você se interessou por esse texto e ainda não leu o livro Design Data-Intensive Applications do Martin Kleppmann, eu super recomendo que você vá atrás dessa leitura! Inclusive, no livro, ele plota uma linha muito interessante entre dados que não se relacionam até dados que possuem muitas conexões.

Ref:

Você tem alguma sugestão, complemento ou crítica? Gostaria de saber mais sobre, deixa nos comentários pra eu poder ler 💜

Processos em Elixir

Willian Frantz — Sat, 28 Nov 2020 18:20:19 +0000

Para quem é este texto?

Este texto vai ser um pouco mais teórico, então se você está buscando entender melhor sobre como os processos em Elixir funcionam, continue lendo...

Por que estudar processos?

Como diria Joe Armstrong, um dos criadores do Erlang:

"O Erlang foi projetado desde o começo para ser uma linguagem de programação funcional, que permitisse a criação de programas concorrentes e distribuídos." - citado em Programming Erlang, Software for a concurrent world.

E assim como Erlang, o Elixir também possui essas mesmas características, e lidar com programas concorrentes tem se tornado cada vez mais uma necessidade real no mundo do Desenvolvimento de Software.

Por isso, lidar com processos e suas abstrações no Elixir é um tópico extremamente importante, não só para conseguirmos aprimorar os nossos projetos, mas também para entender como a linguagem, frameworks e bibliotecas disponíveis nesse ecossistema funcionam.

Por onde começar?

Elixir atualmente possui diversos tipos de abstrações de processos, como por exemplo: Tasks, Agents, GenServers e Supervisors... Onde cada abstração possui a sua própria responsabilidade definida.

É importante estar por dentro deste mundo de abstrações de processos desde a parte mais básica - utilizando spawn/receive - até a criação de processos com GenServers e Supervisors, já que estamos falando sobre uma linguagem de programação concorrente.

Supondo que precisamos criar um módulo que será responsável por tratar detalhes específicos da funcionalidade do nosso produto, que não necessariamente precisam ser executados de forma síncrona, como um disparador de emails, ou até mesmo um disparador de tokens para um sistema 2FA (2 Factor Authentication).

Ambos são exemplos de aplicações boas para ter um processo secundário rodando.

Mas como eu posso começar a trabalhar com processos?

Iniciando com `spawn/1`

Uma das formas que tem funcionado muito bem para mim tem sido tentar entender como funcionavam os processos em Elixir desde o mais básico, utilizando somente spawn/1.

Dito isso, vamos começar com um exemplo:

Digamos que eu precise criar um processo que irá esperar uma mensagem e disparar um IO.inspect/1 (Função de inspecionar o elemento) com os argumentos recebidos.

# módulo que irá disparar as mensagens
defmodule DispatchMessage do
  @moduledoc """
  Process that will await for a message, dispatch when
  received and terminate. 
  """

  @spec start_link() :: pid()
  def start_link() do
    spawn(&wait_message/0)
  end

  defp wait_message() do
    receive do
      {:inspect, data} -> IO.inspect(data)
    end
  end
end

Ele irá executar uma simples atividade de forma assíncrona e encerrar.

Podemos checar isso da seguinte forma:

iex> pid = DispatchMessage.start_link()
#PID<0.119.0>

iex> Process.alive? pid
true

iex> send pid, {:inspect, %{hello: :world}}
%{hello: :world}

iex> Process.alive? pid
false

Podemos ver com o Process.alive?/1 que o processo foi encerrado após executar a sua task de IO.inspect(data).

Mas o que exatamente aconteceu quando executamos este trecho de código no iex?

O DispatchMessage.start_link/0 retornou um PID (Process ID), que é o que usaremos para nos comunicar com o processo que acabamos de criar.

Já o send/2 é a função que usamos para enviar uma mensagem para o processo (PID) que criamos. Este mesmo processo já estava esperando receber uma mensagem a partir do trecho: wait_message/0.

Ciclo de vida

Existem alguns detalhes importantes para mencionar sobre o ciclo de vida desses tipos de processos.

Os processos criados a partir do spawn/1 por padrão irão executar uma task simples e encerrar.
Apesar de estarmos paralelizando o projeto utilizando processos, nosso processo só será capaz de executar um comando por vez.
Chamadas em excesso podem fazer com que o processo precise enfileirar as demais chamadas e isso pode causar timeout em chamadas síncronas (pode acontecer se você estiver usando GenServer handle_call/3).
Podemos determinar se esse processo está esperando por um input utilizando a estrutura de receive.

iex> pid = spawn(fn -> 
...>   receive do 
...>     {:msg, msg} -> IO.puts("Recebi uma mensagem #{msg}")
...>   end
...> end)

iex> send pid, {:msg, "oi"}
"Recebi uma mensagem oi"

Podemos definir também loops e até mesmo simular um estado interno para processos desse tipo, por exemplo:

defmodule StatefulProcess do
  @moduledoc """
  Stateful process abstraction using spawn/1
  """

  @spec start_link() :: pid()
  def start_link() do
    spawn(&loop/0)
  end

  @spec add_data(pid(), map()) :: tuple()
  def add_data(pid, data) do
    send pid, {:msg, data}
  end

  @spec list(pid()) :: atom()
  def list(pid), do: send pid, :list

  defp loop(), do: loop([])
  defp loop(state) do
    receive do
      {:msg, map_msg} ->
        state ++ [map_msg]
      :list ->
        IO.inspect(state)
        state
    end
    |> loop()
  end
end

Acabamos de criar um módulo de processo com estado interno que irá iniciar vazio e incrementará a lista de estado a partir das chamadas add_data/2

ex:

iex> pid = StatefulProcess.start_link
#PID<0.231.0>

iex> StatefulProcess.add_data pid, %{hello: :world}
{:msg, %{hello: :world}}

iex> StatefulProcess.list(pid)
[%{hello: :world}]
:list

A grande sacada deste novo módulo é que quando iniciarmos o processo pelo c:start_link/0, o mesmo não irá terminar após alguma execução (seja ela: c:add_data/2 ou c:list/1), além de que ele também irá armazenar o estado atualizado a partir do c:add_data/2.

Conclusão

Perceba a quantidade de possibilidades que temos somente com a implementação mais básica de processos em Elixir: imagine o que podemos fazer usando as demais abstrações acima!?

A ideia deste texto era desmistificar processos com Elixir, mostrar algumas abordagens usando spawn/1 e receive-do e destacar alguns pontos importantes sobre ciclo de vida dentro da linguagem.

Os tópicos abordados neste texto podem servir para os demais tipos de processos. Pretendo escrever mais sobre as outras abstrações!

Até mais...

Protocolos com Elixir

Willian Frantz — Thu, 29 Oct 2020 13:30:57 +0000

Os protocolos são uma forma de alcançar polimorfismo utilizando Elixir. Podemos determinar ações para uma função genérica baseado no tipo de dado inserido.

Digamos que você precisa implementar uma função que será responsável por recuperar o primeiro elemento de uma lista.

Teríamos algo mais ou menos assim:

defmodule MyList do
  def first_item([item | _list]), do: item
end

Usando este exemplo no IEx, conseguimos visualizar o seu funcionamento:

iex> my_list = [1, 2, 3, 4, 5, 6, 7]
[1, 2, 3, 4, 5, 6, 7]
iex> MyList.first_item(my_list)
1

Uma vez que criamos este módulo MyList e definimos a função para receber uma lista como parâmetro através de pattern matching, a sua implementação fica limitada a somente listas não-vazias.

O uso de outro tipo de dado como argumento geraria o seguinte erro:

iex> MyList.first_item(%{t: 2, b: 3})
** (FunctionClauseError) no function clause matching in MyList.first_item/1

Podemos resolver esse problema de duas maneiras, onde uma delas seria implementar uma nova função com um guard que cumpra os requisitos para Maps:

defmodule MyList do
  def first_item([item | _list]), do: item
  def first_item(map) when is_map(map) do
    map
    |> Enum.to_list()
    |> List.first()
  end
end

E dessa forma seria possível utilizar maps e listas como argumentos, ex:

iex> list = [1,2,3,4,5,6,7,8,9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
iex> map = %{a: 1, b: 2}
%{a: 1, b: 2}
iex> MyList.first_item(list)
1
iex> MyList.first_item(map)
{:a, 1}

Enquanto isso, a segunda opção para resolver este problema seria implementar um protocolo para essa função e garantir que esse protocolo funcione para as seguintes implementações: [Lista, Map]

Mas como fazemos isso?

Protocolos e Implementações

Fazendo uma breve analogia a linguagens OO (Orientada a Objetos), podemos ver o Protocolo em si como uma Interface, onde iremos definir a assinatura de um método, e as implementações como o famoso @override que usamos para dizer que queremos sobrescrever a implementação de determinada funcionalidade da interface que estamos implementando.

A definição de protocolos é feita através da estrutura defprotocol, da seguinte forma:

defprotocol MyList do
  def first_item(value)
end

Não precisamos dizer como a função first_item/1 irá funcionar, basta indicar que estamos criando esse protocolo e que ele precisa possuir as devidas implementações para funcionar de acordo com o esperado.

Agora vamos fazer as implementações usando defimpl para o nosso caso de aceitar Listas e Maps como argumentos:

defimpl MyList, for: List do
  def first_item([item | _list]), do: item
end

defimpl MyList, for: Map do
  def first_item(map) do
    map
    |> Enum.to_list()
    |> List.first()
  end
end

Conclusão

Com Protocolos nós podemos definir diferentes tipos de comportamentos para uma determinada função, sempre se baseando no tipo de dado que queremos processar.

Um bom exemplo de cenário real para isso é o próprio Jason que usamos para transformar as respostas da nossa aplicação web.

O mesmo possui um protocolo chamado Jason.Encoder, contendo a assinatura do método encode. A partir desta interface podemos implementar diferentes tipos de encoding para json dependendo do tipo de dados que queremos retornar na nossa API.

Elixir GenServer?

Willian Frantz — Wed, 07 Oct 2020 02:55:52 +0000

Primeiramente, oi 👋 me chamo Willian, sou desenvolvedor e pretendo usar esse espaço para compartilhar o pouco que aprendi durante esses últimos anos trabalhando com TI.   Se você é pessoa desenvolvedora back-end e/ou está sempre procurando atualizações, novas tecnologias ou novos conhecimentos, esse texto é para você!

Bom, vem comigo.

Elixir

Se você ainda não conhece a linguagem de programação Elixir, vou deixar alguns links abaixo que considero como sendo os de maior influência para te dar uma leve noção de sintaxe e semântica, porém nada muito profundo, para não te sobrecarregar. 😄

Links:
https://elixir-lang.org/
https://elixirschool.com/pt

Além disso, pretendo postar mais conteúdos sobre e garantir que seja possível acompanhar essa tecnologia, e entender como ela pode funcionar (ou não) para você!

GenServer

O que seria isso?

Ele é um dos módulos que compõem o pacote OTP (Erlang/BEAM). É possível acessar ele a partir do Elixir graças a interoperabilidade que a linguagem oferece.

Diz-se que o GenServer é um tipo de processo, assim como os demais processos que podem ser gerados no Elixir (ex: Agent, Task). O seu diferencial é que os processos que são criados a partir de sua implementação possuem um estado interno; em outras palavras, você pode criar um processo que roda como um servidor à parte, de forma assíncrona, sem interferir na sua aplicação principal, e esse processo terá um estado interno que poderá ser alterado da forma que for mais adequado para suas necessidades.

Ciclo de vida

O ciclo de vida do seu GenServer tende a funcionar da seguinte maneira: inicia -> loop(chama uma função -> gera um novo estado).

Ex:
Suponhamos que você tenha utilizado o GenServer para implementar uma pilha, seria mais ou menos assim:

A sua aplicação inicia essa pilha chamando Stack.start() (você está iniciando o seu processo).

Você pode adicionar elementos ou remover elementos utilizando:

stack.push(value) # value = valor que você deseja adicionar.
stack.pop() # retorna o valor que está no topo da pilha.

Os métodos push/1 e pop/0 se encaixam no loop citado acima, onde você está chamando uma função e atualizando o estado interno do seu GenServer.

⚠️ Lembrando que essa pilha irá executar o push/1 de forma assíncrona por ser implementada usando o método handle_cast.

Exemplo implementação de pilha

Seguindo no exemplo do tópico anterior, se estivesse implementando uma pilha, você iria neste caminho:

defmodule Stack do
  use GenServer

  # {...} Outras implementações como init, start_link, etc...

  def handle_call(:pop, _from, [value | state]), do: {:reply, value, state}
  def handle_call(:pop, _from, []), do: {:reply, nil []}

  def handle_cast({:push, value}, state), do: {:no_reply, [value | state]}

  def push(value), do: GenServer.cast(__MODULE__, {:push, value})
  def pop(), do: GenServer.call(__MODULE__, :pop)
end

E isso rodaria mais ou menos assim:

Curiosidades

O Discord atualmente utiliza Elixir e resolve alguns de seus problemas técnicos utilizando GenServer. Um bom exemplo disso é a implementação de semaphores que foi feito para tratar o gerenciamento dos processos, link: https://github.com/discord/semaphore.

Além disso, existem libs do próprio ecossistema do Elixir que utilizam GenServer, um bom exemplo disso seria a própria lib do kafka_ex, que conecta a sua aplicação ao seu serviço Apache Kafka.

Conclusão

O GenServer é muito utilizado no dia-a-dia de um desenvolvedor Elixir, as vezes até mesmo de forma inconsciente (em libs, frameworks, etc). Por isto, é sempre bom conhecer e saber que ele existe e como ele funciona por baixo dos panos.

Deixarei aqui um repositório com algumas implementações básicas de estruturas de dados:

WLSF / data_structures_ex

Repo to implement data structures using Elixir GenServer

Estruturas de dados usando GenServer (Elixir)

Ex de como executar:

iex
$ Stack.start_link
$ Stack.push 10
$ Stack.pop
-> 10

Repositório do texto: Elixir GenServer?

View on GitHub

Por hoje é só, até a próxima... 👋

DEV Community: Willian Frantz

[Boost]

React Native em Alta Performance: Expo Modules, C++ e SIMD (ARM NEON)

Casamento de Padrões em Elixir

Consumindo GraphQL com Elixir?

O que é GraphQL?

Como consumir um Endpoint com Elixir?

Conclusão

5 curious facts about Elixir

1. Functional, but Dynamic too

2. There's No Assign Operator

3. Elixir Goes Meta

4. How Elixir Deals with Strings

5. There Are No Loops

In Conclusion

Mas e os loops em Elixir?

High Order Functions

Recursividade

Conclusão

Behaviours em Elixir

Cenário

Problema

Behaviours

Conclusão

A salada de frutas dos modelos de dados

Modelo Chave-Valor

Modelo de triplas

Modelo de Documentos

Modelo Relacional

Modelo de Grafos

Conclusão

Processos em Elixir

Para quem é este texto?

Por que estudar processos?

Por onde começar?

Iniciando com spawn/1

Ciclo de vida

Conclusão

Protocolos com Elixir

Protocolos e Implementações

Conclusão

Elixir GenServer?

Elixir

GenServer

O que seria isso?

Ciclo de vida

Exemplo implementação de pilha

Curiosidades

Conclusão

WLSF / data_structures_ex

Repo to implement data structures using Elixir GenServer

Estruturas de dados usando GenServer (Elixir)

Iniciando com `spawn/1`