Forem: Renato Alencar

Introdução ao Clojure Component

Renato Alencar — Mon, 27 Nov 2023 23:16:20 +0000

Se você chegou até aqui já deve saber que Clojure é uma linguagem de programação funcional baseada em Lisp que tem ganhado popularidade no Brasil nos últimos anos, principalmente por causa da Nubank. Na minha experiencia pessoal, Clojure tem sido uma linguagem com uma entrada um pouco difícil, algumas coisas são complicadas de inicio, mas você ganha tração bem fácil à medida que você vai tentando se aprofundar.

Algo que eu tenho notado é a falta de material mais profundo sobre Clojure em português, o que torna difícil para brasileiros em geral se aprofundarem no aprendizado da linguagem e na capacidade de gerar discussões em torno da linguagem e dos padrões que a comunidade cria em volta dela. Parte talvez do sucesso que o JavaScript, em especial no Brasil, tenha sido talvez devido a quantidade crescente de usuários e comunidades em português que surgem. Por isso decidi escrever esse artigo, e talvez outros, sobre como tem sido aprender Clojure, como um hobby nas horas vagas. Em especial, nesse artigo sobre a lib Component do Stuart Sierra.

Por que usar Componentes?

Stuart Sierra costumava trabalhar na Cognitect como consultor e desenvolvedor, e analisando os problemas na forma como comumente desenvolvedores estruturavam o estado de suas aplicações, em especial coisas que tem características de singleton, como um pool de conexão com bancos de dados, caching ou partes separadas de uma aplicação, criou um pequeno framework baseado na ideia de injeção de dependência e gerenciamento de estado da orientação a objetos: O Component.

A questão é que temos o hábito de tentar encaixar tudo no modelo MVC, e tentar ver qualquer aplicação como uma extensão disso, tendo um banco de dados, visualização e seja lá o que você considere como lógica/modelo de negocio, sendo que na realidade as coisas estão mais para um spaghetti em formato de integrações com cache, serviços de terceiros, filas de jobs, etc. Então Stuart Sierra, definiu baseado nisso um framework que poderia criar uma abstração generalizada para lidar com esse problema, onde a ideia é:

Criar componentes que guardem a responsabilidade de manter uma parte do estado da aplicação;
Definir um limite claro entre esses componentes;
Definir como lidar com o ciclo de vida desses componentes, cada componente tem que saber como inicializar a si próprio e e como parar;
Definir as dependências entre componentes de forma explícita e que respeite os limites entre os componentes e as partes da aplicação.

Mas como que faz isso? Ajuda aí, cara!

Tudo isso começou semana passada, comigo tentando fazer alguns experimentos com Clojure, montar um web service simples que integrasse com banco de dados e me permitisse fazer algumas operações. Você precisar conectar com o banco e manter a mesma conexão (ou um pool) para usos posteriores, afinal você não vai criar uma nova conexão com o banco toda vez que precisar responder a uma requisição. A forma mais simples de fazer isso pode ser usando um atom mesmo:

(ns example-atom
  (:require [ring.adapter.jetty :refer [run-jetty]]
            [monger.core :as mg]
            [monger.collection :as mc]))

(def database (atom nil))

(defn connect-db! [uri]
  (swap! database (fn [db] (-> uri
                               mg/connect-via-uri
                               :db))))

(defn list-users! []
  (mc/find-maps @database :users))

(defn handler [request]
  {:status 200
   :body (clojure.string/join "\n" (list-users!))})

(defn -main
  [& args]
  (connect-db! (System/getenv "DATABASE_URL"))
  (run-jetty handler {:port 3000}))

Simples, né? Parece até fácil demais para ser verdade. O problema é que quando isso cresce muito, a tendência é que vai ser bem complicado saber que tem acesso à essa conexão, devido ao fato de que essa dependência é implícita, além disso o acesso é a uma variável global e mutável. O outro problema comum é a necessidade de se adicionar cada vez mais dependências externas, que podem ser acessadas por um estado global na aplicação. Stuart Sierra explica isso com detalhes e com bons exemplos em Clojure in the Large, onde ele conta a experiencia dele lidando com esse tipo de problema em aplicações de larga escala.

Isolando o banco de dados

Como o problema inicial nesse exemplo é o banco, vamos começar por ele, esse na verdade é o exemplo clássico incluso no próprio README do projeto Component. Aqui, tudo se baseia em três coisas: o conexão com o banco tem um ciclo de vida, eu devo poder acessar ela na aplicação para poder consultar e inserir objetos e eu devo conseguir gerenciar isso como um estado da aplicação. Para começar vamos definir o que seria exatamente um componente banco de dados, o que devemos manter como estado e como gerenciar o ciclo de vida:

Um banco de dados pode ser caracterizado aqui como a URL de conexão, a conexão em si e o objeto banco de dados onde a biblioteca faz as consultas;
Eu preciso me conectar ao banco quando a aplicação e iniciar e guardar o banco em si e a conexão para ser fechada depois;
Eu preciso fechar a conexão quando a aplicação parar ou pelo menos permitir faze-lo.

Em Clojure podemos definir os dados com um Record, que é um tipo de dados que tem a implementação de map e que são utilizados como tipo para guardar dados em formato de chave-valor.

(defrecord Database [uri database connection])

(defn create-database [uri]
  (let [{:keys [db conn]} (mg/connect-via-uri uri)]
    (map->Database {:uri uri
                    :database db
                    :connection conn})))

Agora que sabemos como encapsular nosso banco de dados, precisamos encapsular o próprio ciclo de vida dele. O Component usa o conceito de Protocolos do Clojure para resolver isso, inclusive protocolo é um conceito tao poderoso por si só que daria um artigo inteiro. O protocolo em questão é o Lifecycle. Usando um protocolo em comum, o framework sabe como iniciar e como parar qualquer componente, assim você só tem que se preocupar com a implementação. Além de definir o componente em si, é interessante definir uma função (pura) que crie o componente, um constructor.

;;
;; Todo o ciclo de vida do banco de dados
;; fica encapsulado em um componente.
;;
(defrecord Database [uri database connection]
  component/Lifecycle

  (start [component]
    (let [{:keys [conn db]} (mg/connect-via-uri uri)]
      (assoc component :database db
                       ::connection conn)))

  (stop [component]
    (-> component ::connection mg/disconnect)
    component))

;;
;; O construtor tem que ser uma funcao pura
;;
(defn new-database [uri]
  (map->Database {:uri uri}))

Mas e o web server?

Bem, nesse momento, você talvez já teve algum tipo de epifania e pensado: "Mas o servidor web também se encaixa nesse padrão". Sim, e vamos encapsular ele também:

;;
;; O web server pode seguir o mesmo protocolo
;; e principios que o banco de dados.
;;
(defrecord WebServer [port app]
  component/Lifecycle

  (start [component]
    (assoc component
      ::jetty
      (run-jetty (-> component :app :handler)
                 {:port port})))

  (stop [component]
    (-> component ::jetty .close)
    component))

(defn new-web-server [port]
  (component/using
    (map->WebServer {:port port})
    ;; Declaramos explicitamente a dependencia
    ;; de um componente `:app`.
    [:app]))

Aqui nós adicionamos algo novo: a função component/using. Ela é responsável poder deixar explicito que um componente depende de outro, nesse caso o app, que possui uma chave handler. Nesse caso o handler deve ser uma função que é responsável por responder a requisições.

Como que junta isso tudo?

Agora vamos precisar de um componente App, que deve depender do banco para fazer as consultas necessárias, usando esse componente vamos passar o banco de dados pelo map da requisição para ser usado internamente pelo handler.

;;
;; Associa um valor `value` a um chave `key` no
;; primeiro argumento da funcao `f`.
;; 
;; Espera-se que `f` seja um handler que possa
;; ser usado com o Ring.
;;
(defn wrap-assoc [f key value]
  (fn [request] (f (assoc request key value))))

(defrecord App [database handler]
  component/Lifecycle

  (start [component]
    (let [database (-> component :database :database)]
      (assoc component :handler
                       (wrap-assoc handler :database database)))))

(defn new-app [handler]
  (component/using
    (map->App {:handler handler})
    [:database]))

(defn list-users-handler [request]
  {:status 200
   :body (clojure.string/join "\n"
           (-> request
               :database ;; Aqui nós acessamos a chave `:database`
                         ;; que foi associada pelo componente `App`.
               (mc/find-maps :users)))})

Como eu inicio a aplicação agora?

Com tudo definido, só precisamos juntar tudo em um map, usando a função component/system-map. Aqui você pode criar uma função pura que é responsável por criar o sistema em si. E então chamar component/start nesse map, dentro da função -main.

;;
;; Apesar de podermos fazer isso diretamente no `-main`, aqui
;; podemos separar a responsabilidade de interpretar as
;; opcoes e passar para os respectivos constructores dos
;; componentes.
;;
(defn system [& options]
  (let [{:keys [database-url port]} options]
    (component/system-map
     :database (new-database database-url)
     :app      (new-app list-users-handler)
     :server   (new-web-server port))))

(defn -main
  [& args]
  (component/start (system :database-url (System/getenv "DATABASE_URL")
                           :port         3000)))

Considerações finais

Você pode estar se perguntando por que eu não usei Compojure ou por que eu usei MongoDB como exemplo. Bem, a intenção desse exemplo é de ser focado no Component, e ao mesmo tempo como ele pode ser usado em conjunto com outras ferramentas. Eu tentei evitar ao máximo adicionar a necessidade de conhecimento sobre outras ferramentas para facilitar o entendimento do exemplo.

O código com as configurações todas no ponto de rodar tá no GitHub em https://github.com/renatoalencar/component-example.

Referências

https://github.com/stuartsierra/component
Clojure in the Large: https://www.youtube.com/watch?v=1siSPGUu9JQ
Components Just Enough Structure: https://www.youtube.com/watch?v=13cmHf_kt-Q

Why Should You Learn OCaml?

Renato Alencar — Wed, 08 Nov 2023 20:56:50 +0000

When I decided to learn OCaml, one of the first talks I watched was Yaron Minsky's 'Why OCaml?'. Where he presents some of the reasons why Jane Street have choose OCaml as the language they would use to build almost everything within the company. What is interesting, is that OCaml was the language I've choose for very specific and well though reasons that kept being true with time and experience with the language.

Functional programming

A few years ago I've been focusing a lot on functional programming, which I believe to be the best way of writing software and its counterparts. Although one can use functional programming elements in languages like Python and Ruby, the idioms are still designed towards a more Object Oriented approach, which makes such idioms a lot of times almost impossible to understand, mostly when used in conjunction.

Python and Clojure

Python was the first language I could say I mastered in depth, back in 2012, since then I have a certain love for simplicity, and a lot of that simplicity comes from its influences from Lisp.

Clojure being functional and with its syntax inherited from Lisp, easily caught my attention, I spent a lot of time focused on the idioms of the language. But essentially, there was something missing, like a good type system (types and Clojure are a very deep rabbit hole) and the dependency on the JVM (what's actually good on the domains Clojure is mostly present as a language). Moreover, the tooling it's reasonably complicated, there's a lack of documentation and the community tends to be very consulting and enterprise focused.

Haskell

I tried Haskell, but although it's an interesting language, there's a few things to consider. The whole tooling tends to be heavyweight, for example the Docker image has 700 MB (it was more than 1 GB when I first tried). Moreover, there's a certain overhead on doing more practical things, something that is easier in Clojure for instance with state, using just an atom.

Enters OCaml

OCaml makes things a little bit different, the syntax closer to ML with the possibility to run side effects without much complexity helps who's learning, also making experimentation and a more progressive design easier.

It isn't necessary to understand the IO monad to make a simple Hello World, but it is possible to run everything behind a monad if that's the interest of the programmer.

main :: IO ()
main = putStrLn "Hello world"

let () = print_endline "Hello world"

print_endline is a direct call, there's no extra abstractions and little to no overhead to understand a single line of code.

If I have the OCaml tooling locally installed, I can even compile a .ml file with a simple ocamlc call without the need of creating a project from scratch just to make little experiments like in Clojure. Babashka solves this problem, but adds an extra burden to newcomers.

(Good) Types

I lot of people don't like types, and I particularly think that TypeScript creates some hardships if you're just trying to build something very simple, besides having a type system I particularly think it's not very pleasant, structural subtyping creates some error messages that are very hard to read and understand.

Moreover, there's another problem: having to always declare types if you want to compiler to verify what you want.

In Python for instance, the following function has to use Any for n and for the return type:

def fib(n):
    if n < 2: return n
    return fib(n - 1) + fib(n - 2)
# def fib(n: Any) -> Any

But the following OCaml code has its types inferred with no further problems:

let rec fib n =
    if n < 2 then n
    else fib (n - 1) + (fib - 2)
(* val fib : int -> int = <fun> *)

Errors become obvious

Functional languages in general have this property of letting that code that probably shouldn't be done that way it was more obvious. With a good type system that becomes even more obvious.

For example, serializers should be pure functions, and shouldn't make queries to the database. For obvious performance and maintenance reasons, also rarely would someone expect that a serializer would be making a database query.

In OCaml, for production systems, we usually use Lwt, which is basically a promise system for asynchronous IO and concurrency. But the Lwt.t type is a monad, and monads have this property of "infecting" everything it touches. Let's suppose you serializer follows the following signature, where it converts a given type t into a string to be sent to another service (probably JSON).

type t

val serialize : t -> string

If you need to convert some information to a string, this is the signature your serializer should have. However, if you need to make a database query inside the serializer, for whatever reason, the function is forced to have another signature:

val serialize : t -> string Lwt.t

Which makes obvious that serialize is doing something that it shouldn't.

Performance

Another important factor is performance. OCaml has very predictable performance, if you come to explore a little on how the compiler works, and how your code ends up in the final Assembly on a given architecture. You'll end up realizing that you are able to predict beforehand with a certain ease how your code it's actually executed.

The OCaml compiler is very well known for emitting very efficient code, which is very good for a language that offers the level of abstraction OCaml does.

Fibonacci is classical example, look how efficient is the final emitted code:

let rec fib n a b =
  if n < 2 then b
  else fib (n - 1) b (a + b)

OCaml uses the least significant bit to differentiate between integers and pointers and make unboxed integer operations. So the code is little different than the expected:

camlExample__fib_268:
        subq    $8, %rsp
.L101:
        cmpq    (%r14), %r15
        jbe     .L102
.L103:
        cmpq    $5, %rax
        jge     .L100
        movq    %rdi, %rax
        addq    $8, %rsp
        ret
.L100:
        leaq    -1(%rbx,%rdi), %rsi
        addq    $-2, %rax
        movq    %rdi, %rbx
        movq    %rsi, %rdi
        jmp     .L101
.L102:
        call    caml_call_gc@PLT
.L104:
        jmp     .L103

Obverse a few details:

All the operation is done directly in the registers.
Recursions are converted into a loop in a efficient manner.
Registers are used are the same as the ones from the calling convention, System V in this case.

Ecosystem

The ecosystem is very accessible if know English, the community Discourse instance is quite crowded and the people involved in the libraries and the language almost always answer people on the forum. Which is very cool, since you have a direct perspective from the people that work on that instead of only a direct user of the language of library.

Where to begin?

I recommended ocaml4noobs in the Portuguese version of this article, but for English the Get Started docs are great!
Real World OCaml is a little more advanced and for more practical uses: https://realworldocaml.org/.
OCaml Programming: Correct + Efficient + Beautiful with theoretical and more computer science focused content: https://cs3110.github.io/textbook/cover.html.

Por que aprender OCaml?

Renato Alencar — Thu, 02 Nov 2023 14:00:23 +0000

Quando eu decidi aprender OCaml, uma das primeiras palestras que assisti foi a Por que OCaml? do Yaron Minsky. Onde ele apresenta algumas das razões pelas quais a Jane Street escolheu OCaml como a linguagem que iriam usar para construir quase tudo dentro da empresa. O que é interessante, é que OCaml foi uma linguagem que escolhi por motivos bem específicos e pensados que se mantiveram verdade com o tempo e experiência com a linguagem.

Programação funcional

Há alguns anos que tenho focado bastante em programação funcional, que acredito ser uma melhor forma de escrever software que suas contrapartes. Apesar de se poder usar elementos de programação funcional em linguagens como Python e Ruby, os idiomas dessas linguagens ainda são voltados para um modelo mais baseado em Orientação a Objetos, o que torna os idiomas funcionais muitas vezes quase impossíveis de entender.

Python e Clojure

Python foi a primeira linguagem que dominei com maior profundidade, lá em 2012, desde então tenho um certo amor pela simplicidade. Muita dessa simplicidade vem das influencias de Lisp que a linguagem possui.

Clojure já sendo funcional e com uma sintaxe próxima do Lisp, me chamou atenção facilmente, passei bastante tempo focado aprendendo os idiomas da linguagem. Mas essencialmente faltavam algumas coisas, como um bom sistema de tipos (tipos e Clojure é uma toca do coelho bem funda) e a dependencia na JVM (o que é bom no tipo de domínio onde Clojure é presente como linguagem). Além disso, o tooling é razoavelmente complicado, falta documentação em algumas coisas e a comunidade tende a ser muito focada em enterprise ou consultoria.

Haskell

Tentei gostar de Haskell, mas apesar de Haskell ser interessante, algumas coisas pesam bastante. Todo o tooling tende a ser pesado, exemplificando a imagem Docker tem 700 MB (na época passava de 1GB). Além disso, há um certo overhead até conseguir fazer algo mais prático, algo que já é mais fácil em Clojure por exemplo com estado, usando apenas um atom.

Entra OCaml

OCaml já faz as coisas de uma forma um pouco diferente, a sintaxe mais próxima do ML com a possibilidade de rodar side-effects sem muita complicação ajuda a quem está tentando aprender, além de facilitar experimentação e um design mais progressivo.

Não é necessário entender a monad IO do Haskell para poder fazer um simples Hello World, mas é possível rodar tudo atrás de monads se for do interesse de quem tá programando.

main :: IO ()
main = putStrLn "Hello World"

let () = print_endline "Hello World"

print_endline é uma chamada direta, não há abstrações extras bem pouco overhead para entender essa única linha de código.

Se eu possuir algum tooling de OCaml instalado localmente, eu ainda consigo compilar um arquivo .ml com um simples ocamlc sem precisar criar um projeto inteiro do zero só para fazer pequenos experimentos como em Clojure. O Babashka resolve esse problema, mas adiciona mais um overhead para quem está aprendendo.

Tipos (bons)

Muita gente não gosta de tipos, Rich Hickey que o diga. E eu particularmente acho que TypeScript cria várias dificuldades se você tá só tentando implementar algo simples, além de ter um sistema de tipos que eu particularmente acho desagradável, subtipagem estrutural cria mensagens de erro péssimas com objetos grandes.

Além disso, entra outro problema: ter que sempre declarar os tipos se você quiser que o compilador verifique o você quer. Isso graças a necessidade de se juntar tipos abstratos com subtipagem.

Em Python por exemplo, a seguinte função vai ter que usar Any para n e para o valor de retorno:

def fib(n):
    if n < 2: return n
    return fib(n - 1) + fib(n - 2)
# def fib(n: Any) -> Any

Já o seguinte código em OCaml tem seus tipos inferidos sem problema algum:

let rec fib n =
    if n < 2 then n
    else fib (n - 1) + fib (n - 2)
(* val fib : int -> int = <fun> *)

Erros ficam óbvios

Linguagens funcionais em geral tem essa propriedade de deixar aquele código que provavelmente não deveria ser feito que você fez mais óbvio. Com um bom sistema de tipos, isso fica ainda mais óbvio.

Por exemplo, serializers deveriam ser funções puras, e não fazer consultas ao banco. Por questões óbvias de performance, de manutenção, e raramente alguem espera que um serializer esteja fazendo um consulta ao banco.

Em OCaml, para sistemas em produção, normalmente utilizamos Lwt, que é basicamente um sistema de promises para IO assíncrono e concorrência. Acontece o tipo Lwt.t é uma mônada, e mônadas tem essa propriedade interessante de "contaminar" tudo que elas tocam. Vamos supor que seu serializer tenha a seguinte assinatura, você converte um dado do tipo t para uma string a ser enviada para outro serviço (provavelmente JSON).

type t

val serialize : t -> string

Se você só precisa converter a informação pra string, é essa a assinatura que o seu serializer deve ter. Porém, se você precisa fazer uma consulta ao banco dentro de serialize, por qualquer que seja o motivo, a função é forçada a ter outra assinatura:

val serialize : t -> string Lwt.t

O que torna óbvio que serialize tá fazendo algo que não deveria.

Performance

Outro fator importante, é performance. OCaml tem performance bem previsível, se você chegar a explorar um pouco sobre como o próprio compilador funciona, e como seu código final fica em Assembly na arquitetura em uso. Você acaba percebendo com o tempo, que você é capaz de perceber de antemão com uma certa facilidade como que o seu código vai ser executado em máquina.

O compilador do OCaml já é bem conhecido por emitir código bem eficiente, o que é muito bom pra uma linguagem com o nível de abstração que o OCaml oferece.

Talvez um exemplo clássico seja Fibonacci, veja como emite código eficiente:

let rec fib n a b =
  if n < 2 then b
  else fib (n - 1) b (a + b)

OCaml usa o bit menos significativo pra diferenciar inteiros de ponteiros e fazer cálculo com inteiros unboxed. O código fica um pouco diferente do que se esperaria, mas ainda assim muito performático:

camlExample__fib_268:
        subq    $8, %rsp
.L101:
        cmpq    (%r14), %r15
        jbe     .L102
.L103:
        cmpq    $5, %rax
        jge     .L100
        movq    %rdi, %rax
        addq    $8, %rsp
        ret
.L100:
        leaq    -1(%rbx,%rdi), %rsi
        addq    $-2, %rax
        movq    %rdi, %rbx
        movq    %rsi, %rdi
        jmp     .L101
.L102:
        call    caml_call_gc@PLT
.L104:
        jmp     .L103

Observe alguns detalhes:

Todo o cálculo é feito diretamente nos registradores;
A recursão é convertida em um loop de forma eficiente;
Os registradores usados são os mesmos dos parâmetros da convenção de chamada.

Ecossistema

O ecossistema é bem acessível se você souber inglês pelo menos, o forúm é bem movimentado e as pessoas envolvidas tanto na linguagem quanto nas bibliotecas quase sempre respondem as pessoas lá mesmo. O que é bem legal, já que você tem a perspectiva diretamente das pessoa que trabalham naquilo ao invés de outro usuário direto da linguagem ou biblioteca.

Por onde começar?

ocaml4noobs é muito bom pra quem quer começar em Português: https://github.com/Camilotk/ocaml4noobs
Real World OCaml já te dá um conteúdo bem mais avançado com casos de usos mais práticos: https://realworldocaml.org/
OCaml Programming: Correct + Efficient + Beautiful com conhecimentos teóricos de Ciência da Computação aplicados à linguagem: https://cs3110.github.io/textbook/cover.html