A construção do código do Catarse Assinaturas (para leigos!)

Hoje vim contar um pouco sobre o processo de construção do Catarse Assinaturas por dentro. Você vai conhecer melhor as entranhas do código (que é open source, como sempre!) numa visão para leigos. Para isso, vou usar analogias, pois essa foi a única maneira que eu encontrei para explicar a mim mesmo o que os programadores do Catarse estavam falando rsrs.

Algumas das conversas que rolam no Slack do Catarse, na sala #devs . Eles falam português?

A decisão por uma infra-estrutura nova

Desde o início do projeto, optamos por criar o Assinaturas em uma infra-estrutura nova. Queríamos deixar de usar uma arquitetura monolítica e passar a usar uma arquitetura de microsserviços. Mas hein? Em poucas palavras, a arquitetura de microsserviços nos dá mais agilidade e mais preparo para escalar o Catarse. Se você quiser se aprofundar um pouco mais, vale ler este artigo para entender melhor a diferença entre esses dois tipos de arquitetura.

Para tentar exemplificar a diferença dessa nova arquitetura para a arquitetura atual que temos no Catarse, vou usar uma analogia. E já que estamos falando de arquitetura, porque não usar uma casa como exemplo. (ps: a ideia original da analogia é do Diogo Biazus, nosso eterno Mago do Catarse. Ele fez essa analogia uma vez e eu achei demais!)

Pois bem, se o Catarse fosse uma casa, todos os cômodos, móveis e utensílios dentro dessa casa seriam os pedaços de código que fazem sentido para os usuários — ou seja, as features do site. Hoje, se quisermos melhorar, trocar ou colocar uma feature nova, digamos, uma nova mesa na sala (ou uma ferramenta interna de questionários), nós temos que tirar todos os móveis da casa, desmontar a casa inteira, colocar tudo num caminhão, levar para um centro de mudanças, e então nesse lugar a gente descarrega tudo do caminhão, coloca a nova mesa no meio dos outros móveis, bota tudo dentro do caminhão de novo, leva para o lugar original, monta a casa inteira de novo, e daí então pegamos tudo e colocamos de novo dentro da casa.

Ah, e fazemos isso com os moradores dentro.

Não faz muito sentido né?

A arquitetura de microsserviços vem justamente para melhorar essa lógica: você quer trocar somente uma panela na cozinha? Você pode ir lá e colocar uma panela nova dentro do armário. Simples assim.

Se você é um programador, entende do assunto e chegou até aqui, não se descabele. Essa é só uma ultra simplificação do processo e eu tenho plena consciência que é bem mais complexo que isso.

Exemplificação de como funciona uma arquitetura de micro-serviços (Fonte: ThoughtWorks)

A gente sabia, desde o começo do projeto, que essa decisão faria com que o desenvolvimento do produto demorasse um pouco mais no curto prazo, mas os benefícios no médio e longo prazo sempre foram o suficiente para tomarmos essa decisão.

Além desse benefício claro de termos mais agilidade na construção e evolução do produto, essa opção por uma infra nova vai também preparar o terreno para que, num futuro não tão distante, consigamos transformar o Catarse em algo bem mais amplo do que uma plataforma de crowdfunding. Queremos que outros negócios utilizem nossa infraestrutura através de nossa API (Application Programming Interface), para desenvolver ainda mais o ecossistema crowd no Brasil.

Isso é ainda uma visão, e assunto para um outro post. Mas se você quiser entender melhor o que é uma API, eu recomendo esse animação de pouco mais de 3 minutos.

As incertezas da nova Infra

Quando iniciamos a pesquisa para entender como seria a implementação dessa nova infra, ainda existiam incertezas. Afinal, criar uma nova aplicação requer que ela converse com a aplicação que já temos.

Basicamente, para seguir na analogia da casa: imagina que o Catarse hoje é tudo, menos a cozinha. Ou seja, é o quarto, a sala e o banheiro. E a gente vai e decide construir o Assinaturas (a cozinha). Nós já sabemos que vamos construi-la com uma arquitetura e uma lógica diferente do resto da casa, mas mesmo assim esses espaços precisam dialogar! A cozinha tem que ter uma porta para a sala, a água que chega na cozinha vem dos canos que também passam pelo banheiro, o interruptor da cozinha usa a mesma corrente elétrica do resto da casa e por aí vai.

E era daí que surgiam as incertezas: como vamos fazer para ligar a cozinha com o resto da casa?

Bem, essas incertezas já passaram. A pesquisa de como isso seria feito já terminou, e a cozinha está pronta.

— Isso quer dizer que eu posso colocar meu projeto de assinaturas no ar agora nesse momento?

— Quase. A estrutura da cozinha está pronta, mas ainda estão faltando alguns detalhes (como a pia, um bom jogo de panelas e uma mesa grande). Estamos quase lá, e assim que estiver tudo nos trinques vamos ter um jantar coletivo daqueles.

O batuque é na cozinha

Essa cozinha que estou falando tem um nome: é a API COMUM, ainda somente para uso interno nosso, mas que já está dialogando com o resto da casa (ou seja, o Catarse como você conhece hoje). Essa aplicação é formada por 3 principais serviços: PAYMENT, COMMUNITY e PROJECTS, cada um cuidando de um dos aspectos fundamentais do mecanismo de financiamento coletivo recorrente.

A Documentação da API Comum. Num futuro não muito distante, a ideia é que essa API esteja aberta para que outras pessoas e empresas possam se plugar no Catarse e criarem suas próprias plataformas e ferramentas para o ecossistema crowd, usando nossos serviços.

Seguindo na analogia, imagina que para uma cozinha funcionar, você precisa de um serviço de água (para garantir que a água entre e saia nos lugares certos, com a pressão adequada), um serviço de gás (no local certo do fogão, com toda a segurança necessária) e um serviço de eletricidade (para que você possa ligar todos os aparelhos eletrônicos).

E é nesse ponto que estamos agora. Uma cozinha com os serviços todos funcionando, e a maioria dos seus utensílios no lugar.

Mestre de Obras (ou Pivotal Tracker, para os íntimos)

Seja na programação de um aplicativo ou na reforma da cozinha, planejamento é fundamental. Aqui no Catarse nós usamos o Pivotal Tracker como principal ferramenta de gerenciamento do Time de Produto.

Já testamos milhões de ferramentas nos outros times, mas o PT (Calma! Estou falando do Pivotal Tracker 😜) nunca nos deixou. Usamos ele desde 2011 e não nos arrependemos.

De uma forma bem resumida, o Pivotal te permite criar estórias únicas, e acompanhar o andamento delas no ciclo de Construção — Finalização — Entrega — Aprovação. Além disso, você acompanha a velocidade do seu time (pois cada estória tem pontos, e a quantidade de pontos entregues a cada semana ajudam o algoritmo do pivotal a indicar qual o ritmo de entregas que seu time é capaz de realizar).

As estórias a que me refiro são as linhas de código que, uma vez integradas na plataforma, entregam valor para a comunidade. Imagine que ‘Instalar a geladeira’ fosse uma estória, na nossa analogia. Dá pra viver sem uma geladeira na cozinha? Em tese, sim. Você pode comer só alimentos frescos. Mas a gente entende que geladeira é fundamental para uma cozinha que se preze, logo entendemos que a geladeira precisa estar no lançamento do Assinaturas (digo, da cozinha).

Além de estórias que entregam valor, existem também os bugs e as chores.

Bug é tudo aquilo que, em tese não deveria existir pois é um erro, mas existe e precisa ser solucionado. Pode ser aquele buraquinho na parede, que dá pra conviver por um tempo e, portanto, você deixa para resolver mais tarde. Ou um gás vazando, que você precisa resolver pra ONTEM.

Já uma Chore é aquilo que é essencial, muitas vezes relacionado a infra-estrutura. Basicamente, lembra todo aquele papo que eu falei de construir a base da cozinha e a API? Então, tudo isso são chores, pois apesar de serem trabalhos de base e consumirem um bom tempo, não entregam valor direto para você, usuário (afinal, de nada adianta ter canos maravilhosos de água e gás, se eu não colocar uma geladeira, um fogão, uma mesa e bons utensílios de cozinha para te convidar para jantar).

O Pivotal Tracker do Catarse com algumas estórias do Assinaturas

Ok, mas quais os próximos passos e quando vocês vão lançar o Assinaturas?

Agora que a API Comum está pronta, vamos começar a ver uma porção de estórias sendo entregues em nosso ambiente de testes nos próximos dias (com a cozinha pronta, é hora de colocar tudo no lugar antes do jantar coletivo).

Hoje, já é possível criar um projeto de Assinaturas no ambiente de testes. Além disso, já conseguimos realizar pagamentos direto na API. No entanto, ainda é preciso testar mais alguns pontos antes de darmos essa etapa como entregue. O próximo passo será então finalizar o painel de controle do projeto (onde os realizadores poderão acompanhar a performance de suas campanhas de arrecadação) e as notificações que são disparadas com as ações do Assinaturas (criação de projeto, confirmação de pagamento, resgate de pagamento com erro, etc).

E aí, só então, poderemos partir para a validação final do produto, já na “vida real”. Ou seja, teremos o Assinaturas rodando pra valer, e nossa equipe irá criar um projeto, assinar, errar um pagamento, enviar uma novidade e tudo o mais que é possível e necessário ser testado, para então entregar o Assinaturas na mão de toda a comunidade.

Em resumo, estamos com o prazo bem apertado, trabalhando com a estimativa de realizar o lançamento na última semana de Novembro. Temos ainda muito trabalho pela frente, mas seguimos num ritmo bom e estamos confiantes de que esse lançamento vai ser histórico!

Já vai preparando seu instrumento, pois em breve vamos fazer um belo de um batuque na cozinha 🥁🥁🥁


Só pra descontrair um pouquinho, fica aqui essa imagem do blog da Toggl: