AVISO: esta série é uma fantasia satírica baseada em fatos reais sobre Elixir. Nada aqui deve ser levado ao pé da letra. Ao final de cada capítulo, os fatos por trás da lenda são revelados. Tags: #satire #humor #elixir #enchiridium
Elixir Enchiridium — Tomo V: O Ecossistema
Prefácio do Tomo
No Tomo I, contamos a história de como Elixir nasceu. No Tomo II, abrimos a máquina. No Tomo III, abrimos o OTP. No Tomo IV, abrimos a sintaxe.
Agora, no Tomo V, vamos abrir o ecossistema.
Uma linguagem não vive sozinha. Ela vive de bibliotecas, ferramentas, frameworks, comunidades. O ecossistema Elixir é vasto: Hex, Mix, Ecto, Phoenix, LiveView, Nx, Absinthe, Oban, Broadway, Tesla, Finch, Jason, e milhares de outras bibliotecas. Cada uma resolve um problema. Cada uma tem uma história. Cada uma tem uma lenda.
Este tomo é sobre esse ecossistema. Cada capítulo parte de um fato verificável sobre uma biblioteca ou ferramenta e o transforma em uma crônica fantástica. Porque a verdade sobre o ecossistema Elixir já é fantástica o suficiente.
São cem capítulos. O quinto tomo de dez.
Capítulo 1 — Hex: O Feitiço que Invoca Pacotes
A lenda diz que o Hex é um feitiço. Quando você roda mix hex.info, um sapo aparece no terminal e pergunta se você aceita os termos de uso. Se recusar, ele vira uma dependência quebrada. Se aceitar, ele pula para a próxima linha e some. O sapo nunca mente. O sapo nunca trapaceia.
A verdade é que Hex é o gerenciador de pacotes oficial do ecossistema BEAM. Ele foi iniciado em 2013 por Eric Meadows-Jönsson e anunciado oficialmente junto com o Elixir v0.13.0 em 2014. Hex serve tanto Elixir (via Mix) quanto Erlang (via Rebar3). Em 2018, Eric fundou a Six Colors, empresa que apoia o desenvolvimento do Hex e opera todos os serviços necessários para rodá-lo. Hoje, o Hex.pm hospeda mais de 15.000 pacotes.
A lenda diz que, na primeira vez que um programador publicou um pacote, ele perguntou: "Posso despublicar?" O instrutor respondeu: "Pode. Mas cuidado. O sapo lembra."
O fato por trás da lenda: Hex é o gerenciador de pacotes oficial do ecossistema BEAM, iniciado em 2013 por Eric Meadows-Jönsson e anunciado oficialmente com o Elixir v0.13.0 em 2014. Serve Elixir e Erlang. Hospeda mais de 15.000 pacotes.
Gancho: O feitiço invoca pacotes. Mas há uma coisa que constrói projetos: o Mix.
Capítulo 2 — Mix: O DJ que Compila Projetos
A lenda diz que o Mix é um DJ. Ele toca músicas. Cada música é uma tarefa. mix new toca a música de criação. mix compile toca a música de compilação. mix test toca a música de teste. No final de cada música, algo acontece. O DJ nunca erra. O DJ nunca para.
A verdade é que Mix é a ferramenta de build oficial do Elixir. Ele foi criado em 2012 por Anthony Grimes, que se inspirou no Leiningen do Clojure. Pouco depois, o Mix foi fundido à própria linguagem Elixir e, até hoje, é uma das seis aplicações que fazem parte da linguagem. Ele fornece tarefas para criar projetos (mix new), compilar (mix compile), rodar testes (mix test), gerenciar dependências (mix deps.get), formatar código (mix format) e gerar documentação (mix docs).
A lenda diz que, na primeira vez que um programador rodou mix new, ele perguntou: "Onde está o projeto?" O instrutor respondeu: "Na pasta que o DJ criou."
O fato por trás da lenda: Mix é a ferramenta de build oficial do Elixir, criada em 2012 por Anthony Grimes, inspirada no Leiningen do Clojure. É uma das seis aplicações que fazem parte da linguagem Elixir.
Gancho: O DJ constrói. Mas há uma coisa que empacota: o Release.
Capítulo 3 — Mix Release: O Bolo que Você Assa e Leva para a Festa
A lenda diz que, antes do Elixir 1.9, fazer deploy de uma aplicação Elixir era como assar um bolo sem receita. Você precisava de ferramentas externas, scripts e fé. Depois do Elixir 1.9, você só precisa rodar mix release. O bolo sai pronto. Embrulhado. Com instruções.
A verdade é que o Elixir 1.9 introduziu o comando mix release, que empacota sua aplicação junto com a Erlang VM em uma única unidade deployável. Isso simplificou drasticamente o deploy de aplicações Elixir, que antes dependia de ferramentas como Distillery ou Edeliver. Um release inclui o código da aplicação, as dependências, a VM e um script de inicialização.
A lenda diz que, na primeira vez que um programador rodou mix release, ele perguntou: "Onde está o bolo?" O instrutor respondeu: "Na pasta _build."
O fato por trás da lenda: Elixir 1.9 introduziu mix release, que empacota a aplicação com a Erlang VM em uma única unidade deployável, simplificando o deploy.
Gancho: O bolo está pronto. Mas há uma coisa que testa: o ExUnit.
Capítulo 4 — ExUnit: O Tribunal que Julga Seu Código
A lenda diz que o ExUnit é um tribunal. Cada teste é um julgamento. Cada assert é uma sentença. Se o código passa, ele é absolvido. Se falha, é condenado. O juiz é imparcial. O júri é o compilador. A sentença é executada imediatamente.
A verdade é que ExUnit é o framework de testes unitários do Elixir. Ele fornece assert, refute, assert_raise, assert_receive e outras macros para escrever testes. Testes são organizados em módulos que usam ExUnit.Case. ExUnit é integrado ao Mix, então você roda mix test para executar todos os testes. ExUnit também suporta describe e test para organizar testes, e setup para preparar o ambiente.
A lenda diz que, na primeira vez que um programador rodou mix test, ele perguntou: "Quantos testes eu preciso?" O instrutor respondeu: "Todos."
O fato por trás da lenda: ExUnit é o framework de testes unitários do Elixir. Fornece assert, refute, assert_raise, assert_receive. Testes usam ExUnit.Case. É executado com mix test.
Gancho: O tribunal julga. Mas há uma coisa que documenta: o ExDoc.
Capítulo 5 — ExDoc: O Papagaio que Gera Documentação
A lenda diz que ExDoc é um papagaio chamado Doc. Ele lê seus @doc e repete em voz alta. Se você não escrever nada, ele fica quieto e gera uma página em branco. O mix docs é o comando para alimentar o papagaio com sementes.
A verdade é que ExDoc é a ferramenta oficial de geração de documentação do Elixir. Ela lê os atributos @doc e @moduledoc e gera documentação HTML navegável. ExDoc é usado por praticamente todos os projetos Elixir. Ele suporta Markdown, links, exemplos e agrupamento de funções.
A lenda diz que, na primeira vez que um programador rodou mix docs, ele perguntou: "Onde está a documentação?" O instrutor respondeu: "Na pasta doc."
O fato por trás da lenda: ExDoc é a ferramenta oficial de geração de documentação do Elixir. Lê @doc e @moduledoc e gera HTML.
Gancho: O papagaio documenta. Mas há uma coisa que formata: o mix format.
Capítulo 6 — Mix Format: O Cabeleireiro que Usa Pomada de Unicórnio
A lenda diz que o mix format arruma seu código com pomada de unicórnio. Se você não rodar, seu código fica com o cabelo bagunçado e o compilador zomba. O .formatter.exs é o manual de estilo do cabeleireiro.
A verdade é que mix format é a ferramenta oficial de formatação de código do Elixir. Ela usa um formatador de código opinativo que garante consistência de estilo em toda a comunidade. O arquivo .formatter.exs define quais arquivos formatar e quais plugins usar. O formatador foi introduzido no Elixir 1.6.
A lenda diz que, na primeira vez que um programador rodou mix format, ele perguntou: "Posso escolher o estilo?" O instrutor respondeu: "Não. O estilo é opinativo."
O fato por trás da lenda: mix format é a ferramenta oficial de formatação. Usa um formatador opinativo. .formatter.exs define quais arquivos formatar e plugins.
Gancho: O cabeleireiro formata. Mas há uma coisa que analisa: o Dialyzer.
Capítulo 7 — Dialyzer: O Detector de Mentiras que Chora com any()
A lenda diz que o Dialyzer é um detector de mentiras. Quando encontra um any(), ele chora copiosamente e se recusa a continuar. Se você usar @spec corretamente, ele sorri e te dá um selo de "código honesto".
A verdade é que Dialyzer é uma ferramenta de análise estática para bytecode da BEAM. Ele fornece avisos sobre tipos incompatíveis, código inalcançável e outros problemas comuns. O Dialyxir é uma biblioteca que fornece conveniências para trabalhar com Dialyzer em projetos Elixir.
A lenda diz que, na primeira vez que um programador rodou o Dialyzer, ele perguntou: "Por que está chorando?" O instrutor respondeu: "Porque você tem any() no código."
O fato por trás da lenda: Dialyzer é uma ferramenta de análise estática para bytecode da BEAM. Fornece avisos sobre tipos incompatíveis e código inalcançável. O Dialyxir facilita o uso em projetos Elixir.
Gancho: O detector analisa. Mas há uma coisa que gera propriedades: o StreamData.
Capítulo 8 — StreamData: O Feiticeiro que Gera Dados Aleatórios
A lenda diz que o StreamData é um feiticeiro. Ele gera dados aleatórios. Ele gera listas. Ele gera mapas. Ele gera structs. Ele testa suas propriedades. Se a propriedade falhar, ele encolhe o caso até encontrar o menor exemplo que falha. O feiticeiro nunca erra. O feiticeiro nunca desiste.
A verdade é que StreamData é uma biblioteca de property-based testing para Elixir. Ela permite gerar dados aleatórios e testar propriedades que devem ser verdadeiras para todos eles. Se uma propriedade falhar, o StreamData encolhe o caso para encontrar o menor contra-exemplo. StreamData é feito de dois componentes principais: geração de dados e property-based testing. O módulo ExUnitProperties cuida da parte de testes. StreamData foi criado por Andrea Leopardi.
A lenda diz que, na primeira vez que um programador usou StreamData, ele perguntou: "O que eu testo?" O instrutor respondeu: "Propriedades."
O fato por trás da lenda: StreamData é uma biblioteca de property-based testing para Elixir. Gera dados aleatórios e testa propriedades. Se falhar, encolhe o caso. Foi criado por Andrea Leopardi.
Gancho: O feiticeiro gera. Mas há uma coisa que observa: o Telemetry.
Capítulo 9 — Telemetry: O Olho que Tudo Vê
A lenda diz que o Telemetry é um olho. Ele mede tudo: requisições, queries, erros. E o LiveDashboard mostra tudo em tempo real. O olho nunca dorme. O olho nunca mente.
A verdade é que Telemetry é uma biblioteca de dynamic dispatching para métricas e instrumentação. Ela é leve, pequena e pode ser usada em qualquer projeto Erlang ou Elixir. A ideia é fornecer uma interface única para instrumentação em todo o ecossistema, já que cada biblioteca costumava implementar sua própria camada de instrumentação. O Phoenix integra a Telemetry para medir e reportar métricas padrão do Phoenix, Ecto e da VM Elixir. O LiveDashboard fornece visualização em tempo real.
A lenda diz que, na primeira vez que um programador usou Telemetry, ele perguntou: "O que posso medir?" O instrutor respondeu: "Tudo."
O fato por trás da lenda: Telemetry é uma biblioteca de dynamic dispatching para métricas e instrumentação. Fornece uma interface única para todo o ecossistema. O Phoenix integra a Telemetry para medir métricas de Phoenix, Ecto e VM.
Gancho: O olho observa. Mas há uma coisa que registra: o Logger.
Capítulo 10 — Logger: O Diário Secreto que Só Conta Verdades
A lenda diz que o Logger é um diário secreto. Ele registra tudo. Cada mensagem. Cada erro. Cada aviso. Se você mentir no Logger.info, ele corrige automaticamente e escreve a verdade no Logger.error. O diário nunca mente. O diário nunca esquece.
A verdade é que Logger é o módulo de logging do Elixir. Ele fornece funções como Logger.debug/2, Logger.info/2, Logger.warn/2, Logger.error/2. O Logger foi introduzido no Elixir v0.15.0, lançado em agosto de 2014, como uma nova aplicação que fornece o módulo Logger como a principal API de logging para desenvolvedores. Ele suporta metadata, filtros e backends personalizados.
A lenda diz que, na primeira vez que um programador usou Logger.info, ele perguntou: "Onde está o log?" O instrutor respondeu: "No diário."
O fato por trás da lenda: Logger é o módulo de logging do Elixir. Foi introduzido no Elixir v0.15.0 (agosto de 2014). Fornece Logger.debug/2, Logger.info/2, Logger.warn/2, Logger.error/2.
Gancho: O diário registra. Mas há uma coisa que conecta nós: o Libcluster.
Capítulo 11 — Libcluster: O Feitiço que Junta os Nós
A lenda diz que, para formar um cluster Elixir, você precisa de magia. Você roda libcluster e, de repente, todos os nós se encontram, se cumprimentam e começam a trabalhar juntos. Se um nó morre, os outros sentem falta. Se um nó nasce, os outros dão boas-vindas.
A verdade é que Libcluster fornece um mecanismo para formar automaticamente clusters de nós Erlang, com adesão estática ou dinâmica. Ele fornece um mecanismo de publish/subscribe para eventos de cluster, para que você possa ser notificado quando membros entram ou saem, e fornece um sistema de estratégias plugável. Ele suporta várias estratégias: EPMD, Kubernetes, Gossip, DNS, Rancher, e outras.
A lenda diz que, na primeira vez que um programador usou Libcluster, ele perguntou: "Como isso funciona?" O instrutor respondeu: "Magia com estratégia."
O fato por trás da lenda: Libcluster forma clusters de nós Erlang automaticamente, com adesão estática ou dinâmica. Fornece publish/subscribe para eventos de cluster e um sistema de estratégias plugável.
Gancho: O feitiço junta. Mas há uma coisa que explica os limites: o Teorema CAP.
Capítulo 12 — CAP: O Teorema que a BEAM Ignora (ou Não)
A lenda diz que, quando os aliens criaram a BEAM, eles leram o Teorema CAP e disseram: "Vamos escolher AP." E assim fizeram. A maioria das bibliotecas distribuídas do Elixir fica do lado AP do Teorema CAP.
A verdade é que a maioria das bibliotecas distribuídas do Elixir (Phoenix Pub/Sub, Horde, Swarm, Delta CRDTs) fica do lado AP do Teorema CAP. Elas preferem disponibilidade a consistência estrita. No entanto, existe o Paxtor, uma biblioteca Elixir para construir sistemas distribuídos CP (Consistent and Partition-tolerant) no BEAM. O Paxtor é baseado no PaxosKV, que fornece uma camada de consenso baseada no algoritmo Basic Paxos.
A lenda diz que, na primeira vez que um programador ouviu falar do CAP, ele perguntou: "Qual lado é melhor?" O instrutor respondeu: "Depende do que você não pode perder."
O fato por trás da lenda: A maioria das bibliotecas distribuídas do Elixir fica do lado AP do Teorema CAP. O Paxtor é uma biblioteca CP que usa Paxos.
Gancho: O teorema explica. Mas há uma coisa que a BEAM faz melhor: tolerância a falhas.
Capítulo 13 — Tolerância a Falhas: A Filosofia que Virou Benchmark
A lenda diz que, num benchmark acadêmico, o Elixir foi comparado a outras linguagens concorrentes sob condições de falha. O resultado? "Elixir atingiu o maior throughput e a menor variabilidade de throughput sob condições de falha".
A verdade é que a tolerância a falhas da BEAM é um dos seus pontos mais fortes. Processos isolados, supervisores, árvores de supervisão, "let it crash" — tudo isso faz com que sistemas BEAM se recuperem de falhas de forma quase automática. Um benchmark acadêmico mostrou que Elixir atinge o maior throughput e a menor variabilidade sob condições de falha.
A lenda diz que, na primeira vez que um programador viu um sistema se recuperar sozinho, ele perguntou: "Como?" O instrutor respondeu: "Supervisores."
O fato por trás da lenda: A tolerância a falhas da BEAM é um dos seus pontos mais fortes. Processos isolados, supervisores, árvores de supervisão, "let it crash".
Gancho: A tolerância é a base. Mas há uma coisa que mantém os processos vivos: os supervisores.
Capítulo 14 — Supervisor: As Babás que Nunca Dormem
A lenda diz que os supervisores são babás que dão mamadeira para processos órfãos. Se um processo morre, a babá chora, pega um novo processo no berçário e coloca no lugar.
A verdade é que supervisores são processos que monitoram outros processos (chamados de processos filhos) e os reiniciam quando falham. Supervisores formam árvores de supervisão que fornecem tolerância a falhas e capacidades de auto-recuperação.
A lenda diz que, na primeira vez que um programador viu uma árvore de supervisão, ele perguntou: "Quantos níveis?" O instrutor respondeu: "Quantos você precisar."
O fato por trás da lenda: Supervisores monitoram processos filhos e os reiniciam quando falham. Formam árvores de supervisão.
Gancho: As babás cuidam. Mas há um processo que serve: o GenServer.
Capítulo 15 — GenServer: O Mordomo que Serve Estado em Bandejas
A lenda diz que um GenServer é um mordomo chamado Alfred que guarda o estado do seu sistema em uma bandeja de prata.
A verdade é que GenServer é um comportamento do OTP para construir servidores genéricos. Ele encapsula estado e concorrência, permitindo que você defina callbacks para lidar com chamadas síncronas e assíncronas.
A lenda diz que, na primeira vez que um programador criou um GenServer, ele perguntou: "Preciso implementar tudo?" O instrutor respondeu: "Só os callbacks."
O fato por trás da lenda: GenServer é um comportamento do OTP para construir servidores genéricos. Encapsula estado e concorrência.
Gancho: O mordomo serve. Mas há uma coisa que persiste: o Ecto.
Capítulo 16 — Ecto: O Fantasma que Assombra Bancos de Dados
A lenda diz que Ecto é um fantasma que mora no seu PostgreSQL e escreve queries em latim. Cada Repo.insert é um exorcismo.
A verdade é que Ecto é uma biblioteca de persistência para Elixir. Ele fornece uma camada de mapeamento entre o código Elixir e o banco de dados, com suporte a migrações, queries e transações. Ecto foi iniciado em 2013 e é um dos projetos mais antigos escritos em Elixir. Ele foi criado por Eric Meadows-Jönsson, que também criou o Hex, com orientação de José Valim. Os mantenedores incluem Eric Meadows-Jönsson, José Valim, James Fish e Michał Muskała. Ecto tem quase 3000 commits e 200 contribuidores, sendo um dos maiores e mais antigos repositórios Elixir.
A lenda diz que, na primeira vez que um programador usou Ecto, ele perguntou: "Isso é um ORM?" O instrutor respondeu: "Não. É uma biblioteca de persistência."
O fato por trás da lenda: Ecto é uma biblioteca de persistência para Elixir, iniciada em 2013. Foi criada por Eric Meadows-Jönsson com orientação de José Valim. Tem quase 3000 commits e 200 contribuidores.
Gancho: O fantasma persiste. Mas há uma coisa que conecta tudo: o Phoenix.
Capítulo 17 — Phoenix: A Fênix que Nasceu das Cinzas
A lenda diz que Phoenix é um framework web que invoca uma fênix de verdade. Cada vez que você roda mix phx.server, uma fênix renasce das cinzas no Arizona.
A verdade é que Phoenix é um framework web para Elixir, criado por Chris McCord. Ele foi lançado em 28 de agosto de 2015, após um ano e meio de trabalho, 2500 commits e 30 releases. Chris começou o desenvolvimento do Phoenix Framework em 2011, e a adoção acelerou em 2014/15. Phoenix é escrito em Elixir e roda sobre a BEAM, aproveitando o modelo de concorrência e a tolerância a falhas da máquina virtual. O repositório do Phoenix tem mais de 23.000 estrelas no GitHub.
A lenda diz que, na primeira vez que um programador rodou mix phx.server, ele perguntou: "Onde está a fênix?" O instrutor respondeu: "No Arizona."
O fato por trás da lenda: Phoenix é um framework web para Elixir, criado por Chris McCord e lançado em 28 de agosto de 2015, após 2500 commits e 30 releases. Tem mais de 23.000 estrelas no GitHub.
Gancho: A fênix constrói. Mas há uma coisa que conecta usuários: o LiveView.
Capítulo 18 — LiveView: A Janela para o Multiverso
A lenda diz que, na primeira vez que alguém rodou uma LiveView, uma janela para outra dimensão se abriu no navegador.
A verdade é que Phoenix LiveView permite construir experiências de usuário ricas e em tempo real com HTML renderizado no servidor, sem escrever JavaScript. A versão 1.0.0 foi lançada em 3 de dezembro de 2024, seis anos após o primeiro commit do LiveView. O release 1.0 incluiu recursos dinâmicos de formulário, novas primitivas de stream, e fechou a lacuna para o 1.0. O repositório do LiveView tem cerca de 6.800 estrelas no GitHub.
A lenda diz que, na primeira vez que um programador viu uma LiveView, ele perguntou: "Onde está o JavaScript?" O instrutor respondeu: "Não tem."
O fato por trás da lenda: Phoenix LiveView permite construir aplicações interativas renderizadas no servidor sem JavaScript. Versão 1.0.0 lançada em 3 de dezembro de 2024, seis anos após o primeiro commit.
Gancho: A janela interage. Mas há uma coisa que consulta: o Absinthe.
Capítulo 19 — Absinthe: O Feiticeiro que Fala GraphQL
A lenda diz que o Absinthe é um feiticeiro que fala GraphQL. Ele define schemas. Ele resolve queries. Ele muta dados. Ele nunca erra. Ele nunca mente.
A verdade é que Absinthe é o GraphQL toolkit para Elixir, uma implementação da especificação GraphQL construída para se adequar às capacidades e ao estilo idiomático da linguagem. Os schemas do Absinthe são definidos usando macros fáceis de ler que constroem e verificam sua estrutura em tempo de compilação, prevenindo erros em runtime e aumentando a performance. O repositório do Absinthe tem cerca de 4.400 estrelas no GitHub e mais de 42 milhões de downloads.
A lenda diz que, na primeira vez que um programador usou Absinthe, ele perguntou: "O que é GraphQL?" O instrutor respondeu: "É uma linguagem de consulta."
O fato por trás da lenda: Absinthe é o GraphQL toolkit para Elixir. Schemas são definidos com macros que verificam a estrutura em tempo de compilação. Tem cerca de 4.400 estrelas no GitHub.
Gancho: O feiticeiro consulta. Mas há uma coisa que enfileira: o Oban.
Capítulo 20 — Oban: O Maestro que Orquestra Jobs
A lenda diz que o Oban é um maestro. Ele orquestra jobs. Ele agenda. Ele executa. Ele retenta. Ele nunca perde um job. Ele nunca erra.
A verdade é que Oban é uma biblioteca de processamento de jobs em background para Elixir. Ele é backed by modern PostgreSQL e retém dados de jobs para métricas históricas e inspeção, sendo fundamentalmente diferente de outras ferramentas de processamento de jobs em background. Oban foi desenvolvido e testado ativamente com Elixir 1.8+, Erlang/OTP 21.1+ e PostgreSQL 11.0+. Ele foi criado por Parker Selbert, que é chief architect na dscout e parceiro de sua esposa na Soren, construindo Oban Web e Pro. O repositório do Oban tem cerca de 4.000 estrelas no GitHub.
A lenda diz que, na primeira vez que um programador usou Oban, ele perguntou: "Onde estão os jobs?" O instrutor respondeu: "No banco."
O fato por trás da lenda: Oban é uma biblioteca de processamento de jobs em background, backed by PostgreSQL. Foi criado por Parker Selbert. Tem cerca de 4.000 estrelas no GitHub.
Gancho: O maestro orquestra. Mas há uma coisa que consome: o Broadway.
Capítulo 21 — Broadway: O Rio que Processa Dados
A lenda diz que o Broadway é um rio. Ele recebe dados. Ele processa dados. Ele envia dados. Ele nunca para. Ele nunca transborda.
A verdade é que Broadway é uma biblioteca para construir pipelines de processamento de dados em Elixir. Ele foi anunciado em fevereiro de 2019 como um projeto open source desenvolvido pela Plataformatec, com o objetivo de simplificar pipelines de processamento de dados com Elixir. Broadway permite consumir dados eficientemente de diferentes fontes, conhecidas como producers, tais como Amazon SQS, Apache Kafka, Google Cloud PubSub, RabbitMQ, e outros. Os mantenedores são Marlus Saraiva e José Valim.
A lenda diz que, na primeira vez que um programador usou Broadway, ele perguntou: "Onde estão os dados?" O instrutor respondeu: "No rio."
O fato por trás da lenda: Broadway é uma biblioteca para construir pipelines de processamento de dados em Elixir. Anunciado em fevereiro de 2019. Mantido por Marlus Saraiva e José Valim.
Gancho: O rio processa. Mas há uma coisa que busca: o Tesla.
Capítulo 22 — Tesla: O Feiticeiro que Faz Requisições HTTP
A lenda diz que o Tesla é um feiticeiro. Ele faz requisições HTTP. Ele define middlewares. Ele autentica. Ele retenta. Ele nunca falha. Ele nunca desiste.
A verdade é que Tesla é uma biblioteca de cliente HTTP para Elixir, livremente baseada no Faraday do Ruby. Ela abraça o conceito de middleware ao processar o ciclo requisição/resposta. Você define um módulo com use Tesla e escolhe entre uma variedade de middlewares. O Tesla suporta múltiplos adapters, incluindo Tesla.Adapter.Mint. O autor upstream é Alexander Strizhakov.
A lenda diz que, na primeira vez que um programador usou Tesla, ele perguntou: "O que é um middleware?" O instrutor respondeu: "É uma função que processa a requisição."
O fato por trás da lenda: Tesla é uma biblioteca de cliente HTTP para Elixir, baseada no Faraday do Ruby. Abraça o conceito de middleware. Suporta múltiplos adapters.
Gancho: O feiticeiro faz requisições. Mas há uma coisa que conecta: o Finch.
Capítulo 23 — Finch: O Corredor que Nunca Para
A lenda diz que o Finch é um corredor. Ele corre. Ele faz requisições. Ele nunca para. Ele nunca se cansa. Ele é rápido. Ele é eficiente.
A verdade é que Finch é uma biblioteca de cliente HTTP para Elixir, focada em performance, construída sobre Mint e NimblePool. O Finch é frequentemente usado em aplicações Phoenix para fazer requisições HTTP de forma eficiente. Os direitos autorais são de Christopher Jon Keathley & Nico Daniel Piderman. Ele foi criado em 2020.
A lenda diz que, na primeira vez que um programador usou Finch, ele perguntou: "Por que não usar HTTPoison?" O instrutor respondeu: "Porque Finch é mais rápido."
O fato por trás da lenda: Finch é uma biblioteca de cliente HTTP para Elixir, focada em performance, construída sobre Mint e NimblePool. Criada em 2020.
Gancho: O corredor corre. Mas há uma coisa que serializa: o Jason.
Capítulo 24 — Jason: O Tradutor que Fala JSON
A lenda diz que o Jason é um tradutor. Ele traduz Elixir para JSON. Ele traduz JSON para Elixir. Ele nunca erra. Ele nunca mente.
A verdade é que Jason é uma biblioteca de JSON parser e generator em Elixir puro. O parser e o generator são pelo menos duas vezes mais rápidos que outras bibliotecas Elixir/Erlang (mais notavelmente o Poison). Jason foi criado por Michał Muskała. Ele implementa os padrões 8259 e ECMA 404. O Jason tem mais de 2.100 pacotes dependentes e mais de 166 milhões de downloads.
A lenda diz que, na primeira vez que um programador usou Jason, ele perguntou: "Por que não usar Poison?" O instrutor respondeu: "Porque Jason é mais rápido."
O fato por trás da lenda: Jason é uma biblioteca de JSON para Elixir, criada por Michał Muskała. É pelo menos duas vezes mais rápida que outras bibliotecas. Tem mais de 166 milhões de downloads.
Gancho: O tradutor traduz. Mas há uma coisa que valida: o Ecto.Changeset.
Capítulo 25 — Ecto.Changeset: O Guardião que Valida Tudo
A lenda diz que o Ecto.Changeset é um guardião. Ele valida. Ele transforma. Ele rejeita. Se um dado é inválido, o guardião o rejeita. Se é válido, o guardião o aceita. O guardião nunca erra. O guardião nunca mente.
A verdade é que changesets permitem filtragem, casting, validação e definição de constraints ao manipular structs, geralmente em preparação para inserir e atualizar entradas em um banco de dados. As funções cast/4 e change/2 são os pontos de entrada usuais para criar changesets. Ecto changesets fornecem tanto validações quanto constraints, que são eventualmente transformadas em erros caso algo dê errado.
A lenda diz que, na primeira vez que um programador usou um changeset, ele perguntou: "O que é isso?" O instrutor respondeu: "É o guardião da validação."
O fato por trás da lenda: Changesets permitem filtragem, casting, validação e constraints ao manipular structs. cast/4 e change/2 são os pontos de entrada.
Gancho: O guardião valida. Mas há uma coisa que consulta: o Ecto.Query.
Capítulo 26 — Ecto.Query: A Linguagem que Fala SQL
A lenda diz que o Ecto.Query é uma linguagem. Ela fala SQL. Mas não é SQL. É Elixir. Você escreve queries em Elixir, e o Ecto as traduz para SQL. É mágica.
A verdade é que Ecto.Query fornece a Query DSL. Queries são usadas para recuperar e manipular dados de um repositório. As queries do Ecto vêm em dois sabores: keyword-based e macro-based. A maioria dos exemplos usa a sintaxe keyword-based; a sintaxe macro-based é mais poderosa.
A lenda diz que, na primeira vez que um programador usou Ecto.Query, ele perguntou: "Isso é SQL?" O instrutor respondeu: "Não. É Elixir. Mas vira SQL."
O fato por trás da lenda: Ecto.Query fornece a Query DSL. Queries vêm em dois sabores: keyword-based e macro-based.
Gancho: A linguagem consulta. Mas há uma coisa que migra: as migrações.
Capítulo 27 — Ecto.Migração: O Arqueólogo que Move o Banco
A lenda diz que as migrações são arqueólogos. Elas escavam. Elas movem. Elas transformam. Elas nunca perdem um fóssil.
A verdade é que migrações são usadas para modificar o schema do banco de dados ao longo do tempo. O módulo Ecto.Migration fornece muitos helpers para migrar o banco de dados, permitindo que desenvolvedores usem Elixir para alterar seu armazenamento de forma database-independent. A função up/0 é responsável por migrar o banco de dados para frente. Por padrão, o Ecto executa todas as migrações dentro de uma transação.
A lenda diz que, na primeira vez que um programador rodou uma migração, ele perguntou: "O que é isso?" O instrutor respondeu: "É o arqueólogo movendo o banco."
O fato por trás da lenda: Migrações modificam o schema do banco de dados ao longo do tempo. O módulo Ecto.Migration fornece helpers. up/0 migra para frente.
Gancho: As migrações movem. Mas há uma coisa que tudo conecta: a Application.
Capítulo 28 — Application: O Componente que Pode Ser Iniciado e Parado
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas.
A lenda diz que, na primeira vez que um programador criou uma application, ele perguntou: "O que é isso?" O instrutor respondeu: "É um componente."
O fato por trás da lenda: No OTP, application denota um componente que implementa funcionalidade específica, iniciada e parada como uma unidade.
Gancho: A application é a unidade. Mas há uma coisa que supervisiona: o Supervisor.
Capítulo 29 — Phoenix.PubSub: O Megafone que Todos Ouvem
A lenda diz que o Phoenix.PubSub é um megafone. Você publica uma mensagem em um tópico. Todos os processos inscritos naquele tópico recebem a mensagem. Ninguém fica de fora. Ninguém ouve o que não devia. O megafone é justo.
A verdade é que Phoenix.PubSub é um serviço de Publisher/Subscriber em tempo real. Ele foi projetado para ser flexível e suportar múltiplos backends. Há dois backends oficialmente suportados. Phoenix.PubSub permite que desenvolvedores realizem dispatch customizado passando um módulo dispatcher, que é responsável pelas entregas locais de mensagens. Ele é usado pelo Phoenix para transmitir atualizações do LiveView.
A lenda diz que, na primeira vez que um programador usou PubSub, ele perguntou: "Como o PubSub funciona?" O instrutor respondeu: "Você publica, eles ouvem."
O fato por trás da lenda: Phoenix.PubSub é um serviço de Publisher/Subscriber em tempo real. Projetado para ser flexível e suportar múltiplos backends. Usado pelo Phoenix para transmitir atualizações do LiveView.
Gancho: O megafone distribui. Mas há uma coisa que persiste em disco: o DETS.
Capítulo 30 — DETS: O ETS que Fica no Disco
A lenda diz que o DETS é o irmão do ETS que mora no disco. Ele é mais lento. Ele é mais teimoso. Mas ele sobrevive a reinicializações. Se a BEAM morrer, o DETS continua lá. Esperando. Paciente.
A verdade é que dets (Disk Erlang Term Storage) é um módulo que fornece armazenamento de termos em arquivo. Os termos armazenados, chamados de objetos, são tuplas tais que um elemento é definido como a chave. Uma tabela Dets é uma coleção de objetos com a chave na mesma posição, armazenada em um arquivo. O Dets é usado pela aplicação Mnesia e é fornecido "como está" para usuários interessados em um armazenamento eficiente de termos Erlang apenas em disco.
A lenda diz que, na primeira vez que um programador usou DETS, ele perguntou: "Por que não usar ETS?" O instrutor respondeu: "Porque ETS esquece."
O fato por trás da lenda: DETS é um módulo que fornece armazenamento de termos em arquivo. É usado pela aplicação Mnesia. Fornecido "como está" para armazenamento eficiente de termos Erlang em disco.
Gancho: O DETS persiste. Mas há uma coisa que persiste e distribui: o Mnesia.
Capítulo 31 — Mnesia: O Banco de Dados que Mora na BEAM
A lenda diz que o Mnesia é um banco de dados. Mas não é um banco de dados comum. Ele mora dentro da BEAM. Ele é distribuído. Ele é transacional. Ele é o banco de dados que os aliens criaram para os telefones suecos.
A verdade é que Mnesia é um DBMS de telecomunicações distribuído, apropriado para aplicações de telecomunicações e outras aplicações Erlang que requerem operação contínua e exibem propriedades de soft real-time. Ele tem um modelo de dados híbrido relacional/objeto que é adequado para aplicações de telecomunicações. Os dados no Mnesia são organizados como um conjunto de tabelas, e cada tabela é feita de registros Erlang. Ele também fornece uma linguagem de consulta DBMS, Query List Comprehension (QLC), como uma biblioteca adicional.
A lenda diz que, na primeira vez que um programador usou Mnesia, ele perguntou: "Por que não usar PostgreSQL?" O instrutor respondeu: "Porque Mnesia está dentro."
O fato por trás da lenda: Mnesia é um DBMS de telecomunicações distribuído, apropriado para aplicações que requerem operação contínua e soft real-time. Modelo de dados híbrido relacional/objeto. Cada tabela é feita de registros Erlang.
Gancho: O Mnesia persiste. Mas há uma coisa que empacota tudo: o Release.
Epílogo Parcial do Tomo V
Trinta e um capítulos. Um ecossistema. Mil processos. E um brasileiro que ouviu um sussurro.
Este foi o começo do Tomo V — O Ecossistema, agora com fatos verificados. Ainda faltam 69 capítulos para completar este tomo. Nos próximos, vamos explorar: Ecto.Schema, Ecto.Repo, Phoenix.Router, Phoenix.Controller, Phoenix.View, Phoenix.Channel, Nx, Axon, Bumblebee, Explorer, Scholar, e muitas outras bibliotecas.
Até lá.
Agora, sério: O ecossistema Elixir é vasto. Hex foi iniciado em 2013 por Eric Meadows-Jönsson. Mix foi criado em 2012 por Anthony Grimes. ExUnit testa. ExDoc documenta. Dialyzer analisa. StreamData gera dados aleatórios. Telemetry observa. Logger foi introduzido no Elixir v0.15.0. Libcluster conecta. Paxtor é CP. Ecto foi iniciado em 2013 por Eric Meadows-Jönsson. Phoenix foi lançado em 28 de agosto de 2015 por Chris McCord. LiveView 1.0 foi lançado em 3 de dezembro de 2024. Absinthe é o GraphQL toolkit. Oban foi criado por Parker Selbert. Broadway foi anunciado em fevereiro de 2019. Tesla é baseado no Faraday. Finch é focado em performance. Jason é duas vezes mais rápido que outras bibliotecas. DETS armazena termos em arquivo. Mnesia é um DBMS de telecomunicações distribuído. As capivaras quânticas não são reais — mas deveriam ser. Este artigo é uma fantasia satírica baseada em fatos. Mantenha o aviso para não enganar ninguém.
Top comments (0)