Destrinchando a lib async da App Sauce (baseada em core.async)

[wandersoncferreira]

Dada as ultimas discussões sobre core.async no canal do Telegram, eu resolvi publicar meus estudos sobre a biblioteca async da App Sauce. Os autores da lib são o Nate Jones e o Christopher que apresentam o podcast Funcional Design in Clojure.

Eu trabalhei com eles e tive a oportunidade de ver essa biblioteca em uso em produção e foi bem interessante. O README no repo dos meus estudos contém uma explicação das duas abstrações principais da biblioteca (worker e pipeline) e existe um arquivo de exemplos com um pouco de código utilizando a lib.

Código dos meus estudos (unit): https://github.com/wandersoncferreira/unit

(não aconselho usar esse código sem ser para fins educativos (pois foi para isso que eu re-escrevi))

[wandersoncferreira]

Apesar de simples, esse código basicamente era a infraestrutura para o processamento de diversos eventos em real-time para competições de jogos on-line. Entre os clientes tinham empresas bem grandes do porte da Blizzard.

[wandersoncferreira]

@mauricioszabo dado que você comentou sobre Actors, você pode compartilhar sua experiência com esse estilo de desenvolvimento?

[mauricioszabo]

Eu não trabalhei muito com actors, na verdade. Eu achei meio desajeitado em geral, e no final eu acabaria por usar uma mensageria e conexão entre vários sistemas com k8s (que basicamente é o paradigma de atores mas meio que distribuído). Achei que actors seria melhor porque é mesmo processo e poderia dar certas garantias, mas no fim, não foi minha experiencia no geral

[wandersoncferreira]

Entendi, no projeto que trabalhei com a lib async a maior vantagem foi justamente compartilhar dados em memoria e não passar por um sistema de mensageria externa. Como a aplicação era para jogos online em real-time, recebiamos uma quantidade enorme de mensagens por segundo e diversas métricas e validações eram feitas sobre o estado de cada jogo. Isso era disponibilizado em uma outra API com load menor para os provedores de TV/broadcasters informar na hora o que estava ocorrendo no game.

Um exemplo de worker que existia era um "organizador de eventos" porque a empresa dos jogos diversas vezes enviava eventos fora de ordem e a gente precisava organizar por timestamp do jogo.

Era bem fácil identificar uma nova funcionalidade e colocar ela no pipeline sem alterar nada do que existia antes.

[mauricioszabo]

Aproveitando que estamos no assunto, eu tenho essa talk aqui sobre paralelismo: https://youtu.be/b7cbPjsYUYY