Fala, Juno!

Criando a Juno

Chrysthian Simão, arquiteto front-end na Juno, contou no Fala, Juno! de hoje como foi a experiência de criar a plataforma da Juno. Vem conferir!

criando a juno
Tempo de leitura: 4 minutos

Por Chrysthian Simão, arquiteto front-end na Juno

Olá! Nós somos a Juno, uma intermediadora de pagamentos.

Lançamos a marca e criamos uma nova plataforma com uma nova identidade, trabalhando por pouco mais de um ano nesta transição.

Nesse texto, vamos começar falando sobre a parte de tecnologia. Se você estiver interessado na parte de design da plataforma, produto e aplicativos, fique ligado que em breve vamos falar mais sobre cada uma das etapas.

Cenário

A JUNO surgiu baseada numa plataforma já existente, a do Boleto Fácil. Uma solução monolítica com algumas ferramentas de templates, já com webservices construídos para se comunicarem com a atual camada de view.

Desafio

Implementar uma nova camada de view, que não sobreponha a atual (Boleto Fácil), melhorando a usabilidade em todos os sentidos. Não foi só colorir a Boleto Fácil com um novo estilo de CSS, mudar as imagens e mandar pra frente, nosso principal termômetro era trazer valor ao usuário promovendo a nova marca.

Problema: arquitetura

A JUNO precisava ser escalável, ágil, altamente customizável, disponibilizando aos desenvolvedores atomic design e fornecendo flexibilidade.

Solução

Escolhemos trabalhar com React, mas não precisamos entrar na discussão de “qual framework de front-end é melhor”. Existem vários e vários artigos, que tratam desse tema. E nossa equipe interna também teve várias discussões sobre o assunto.

O resumo da ópera é: todo framework tem pontos positivos e negativos. Aceitamos que, para a nossa realidade, os prós do React superam os contras.

Essa escolha trouxe uma realidade: um dos “contras” da flexibilidade do React é que teríamos que construir as peças do nosso quebra-cabeça, pois não tínhamos um framework já definido junto com essa tecnologia.

Para isso, definimos nossa arquitetura conforme o diagrama a seguir:

criando a juno

As camadas garantem o one-way-data-bind, transporte da informação e responsabilidades claras. Após um ano em desenvolvimento, poucas alterações afetaram este diagrama.

Leia também: Fala, Juno! – Gerenciando uma estratégia de canais

Vamos passar pelas camadas uma a uma:

Components (Ui-Kit): Camada que armazena os componentes (átomos, moléculas e organismos) para que possam ser reutilizados dentro de uma hierarquia. Devem ser auto-contidos, atômicos e permitir propriedades passadas por parâmetros. O React coloca como ferramenta o JSX, que permite a mistura do código HTML dentro de um JS, uma classe react permite a passagem de parâmetros através de “props” e o estado interno do componente através de um objeto interno chamado “state”.

JSX(Page): As páginas da aplicação utilizam os componentes, tantos quantos forem necessários para que o design e a usabilidade sejam atendidos.

Action: Camada responsável por disponibilizar funções a serem chamadas pelas páginas, essas ações podem afetar o estado da aplicação (apenas front-end) e/ou se comunicar com a API (back-end). Caso necessária a comunicação com a API (back-end), é feita uma chamada para a camada de Service, mas uma Action sempre envia uma resposta para o Dispatcher.

Service: Camada estritamente responsável por chamadas de requisição e resposta com a API.

API: Serviço externo que recebe as requisições da aplicação.

Store: Objeto em memória que é responsável por armazenar o estado da aplicação (informações globais como usuário logado) — não confundir com o estado atômico do componente (o “state”).

Dispatcher: Camada que é chamada pela Action para atualizar o estado da aplicação, o Store.

Trafegar dados atualizados no Store também dispara um evento de atualização para as páginas e componentes que estiverem observando o Store.

Também é importante notar que uma Action pode disparar várias chamadas de atualização para os Stores que se aplicarem.

Essas camadas, principalmente as de comunicação, podem ser feitas “na raça”, mas não precisamos sofrer tanto se utilizamos o Redux. Para facilitar, aqui temos uma ótima referência para implantar Redux em um projeto React já existente.

criando a juno

Problema: Componentes, componentes, componentes…

Separar todos os possíveis componentes de uma aplicação desde o nível atômico pode ser uma tarefa hercúlea, e uma atualização em um componente precisa refletir todos os usos, sem nenhum esforço adicional, tornando o estilo e comportamento uniforme.

Solução

Definimos parâmetros gerais de um UI-Kit e fomos atrás de uma paleta de componentes em React, para que os componentes mais comuns como campos de texto e caixas de seleção possam ser atendidos, sem reinventar a roda.

Isso era apenas parte da solução, pegamos componentes de diversas paletas diferentes e customizamos conforme a necessidade. Essa parte do framework foi muito positiva, permitindo escolher quais blocos de montar iríamos utilizar, podendo misturar vários, de várias origens.

Alguns componentes que utilizamos foram:

Ant Design
PrimeReact
React Slick
React-dropzone

Quase lá! Os comportamentos específicos para a nossa plataforma nós conseguimos resolver estendendo as classes originais e modificando conforme necessário.

Mas precisávamos definir os nossos estilos e deixar os componentes com a nossa cara, novamente, sem muito trabalho.

Styled components veio nos resgatar. Conseguimos separar notações de CSS e Less no início das nossas páginas e componentes, sem poluir os métodos de render com grandes blocos de estilo.

Problema: Deploy independente

A JUNO precisava de um deploy independente da plataforma atual (apesar de consumir os seus recursos), subir o front-end precisava ser completamente desacoplado.

Solução

Ao separar toda a camada de view do modelo, utilizamos a AWS para hospedar o código estático, minificado e otimizado em um bucket S3. Subimos o node.js em uma instância EC2 apontando para esse ambiente.

O build pode rodar por linha de comando mas, para evitar erros humanos, automatizamos em uma rotina do NPM.

Isso permite que ações rápidas possam ser tomadas para resolver possíveis problemas, sem afetar as outras soluções.

Conclusão

Aqui compartilhamos em linhas gerais as nossas maiores dores e os nossas soluções para criar uma plataforma nova “From Zero to Hero”. Esperamos que o nosso caminho das pedras ajude a evitar seus percalços e que você possa encontrar um norte com o que a gente aprendeu criando a JUNO.

Um grande abraço. ?

#tamojuno