Ao decorrer dos anos, muito tem se falado em arquitetura de software. Cada vez mais buscamos por aplicações mais rápidas, modernas, escaláveis e de fácil manutenção, porém ainda há um tabu quando falamos em arquitetura de front-end, afinal, por que se preocupar com a arquitetura se são basicamente só telas?
A forma com que estruturamos nossa aplicação front-end é tão importante quanto o back-end, pois de nada adianta termos um “motor de Ferrari” rodando no servidor, se há um mal desempenho e baixa performance na parte visual.
Independente do padrão utilizado em sua aplicação, há alguns pontos de extrema que devem ser observados.
Componentização na prática
O grande segredo para garantir a reutilização de código em seu front–end é desenvolver voltado a componentização. Com outras palavras, podemos dizer que sua aplicação deve funcionar como um quebra cabeça, logo, porque ter uma peça grande e de difícil movimentação, se podemos ter várias peças menores que sejam flexíveis e de fácil manipulação?
Atomic Components
Como bom exemplo de arquitetura voltada a componentização temos a “Atomic Design”, que consiste em dividir a aplicação em “Átomos”, “Moléculas”, “Organismos”, “Templates” e “Páginas”. Os “Átomos” são os componentes de menores unidades: botões, labels e afins; as “Moléculas” os componentes que envolvem a junção de alguns átomos; “Organismos” são a junção das “Moléculas”; “Templates” são elementos maiores no nível de uma página como, por exemplo, um formulário; por fim, as “Páginas” são as navegações dentro da aplicação já utilizando a camada de comunicação externa.
Referência: https://atomicdesign.bradfrost.com/chapter-2/
Descomplicando os Micro Front-ends
Atualmente a arquitetura de Micro Serviços tornou-se o “cream de lá cream” nas aplicações webs modernas, pois garante alta escalabilidade, segregações por contextos e é de fácil manutenção. Antes tínhamos um grande gargalo nas interfaces que, muitas vezes, tinham repetições de código, baixa disponibilidade e outros problemas oriundos de uma aplicação monolito, com isso, surgiu a arquitetura de micro frot-ends, trazendo todos os ganhos e facilidades obtidos por meio dos micros serviços.
Resumidamente, os micro-front-ends são pequenas aplicações visuais que, em seu conjunto, atendem a um ecossistema ou aplicação única e são orquestradas por uma aplicação com a responsabilidade de roteamentos dentre os demais serviços.
Existem diversas maneiras de segregar esses tipos de aplicações, as mais utilizadas são por domínio ou jornadas, sendo domínios a separação entre áreas de um sistema. Por exemplo, em uma aplicação e-commerce temos os domínios de produtos, carrinho de compra e logística. Já o conceito por jornada abrange todo um fluxo de uma navegação do usuário (também conhecido por Use Case), como exemplo o fluxo da escolha de um produto até a área de checkout de compra.
Por mais que em seu conceito os micro front-ends pareçam a melhor das escolhas para o desenvolvimento de aplicações, sua utilização também traz algumas desvantagens, como o aumento significativo de consumo de recursos back-end, maior gestão de códigos, repositórios e pipelines, maior complexidade na correção de problemas simples, necessidade de times maiores de desenvolvimento, maior complexidade para execução de testes integrados e maior tempo para finalização/entrega de um projeto.
Por que gerenciar estado?
Talvez o maior dos dilemas na escolha de padrões e arquitetura para seguir no desenvolvimento front-end está relacionado ao gerenciamento de estado. A escolha de qual biblioteca/padrão aderir para tal responsabilidade pode ditar até que ponto a sua aplicação conseguirá evoluir.
Chamamos de gerenciamento de estado a conduta de um componente em como definir e retornar o valor atual atribuído ao mesmo ou a algum elemento interno. Existem 2 maneiras de gerenciar o estado de um componente, sendo elas local e global. Na local o próprio componente atribui e resgata seu valor atual de forma interna, logo, todos os outros que necessitem obter ou modificar seu estado deverão agir via chamada encadeada. Já na global essa responsabilidade é atribuída a outra camada, facilitando o acesso para toda a aplicação.
FLUX Design pattern
Criado pelo Facebook para resolver o grande gargalo de gerenciar globalmente o estado de seus pequenos componentes, o “FLUX” consiste em dividir o estado dos componentes em 3 camadas segregadas do mesmo.
A primeira camada, a “View”, é tudo o que se refere a elementos visuais, como HTML. A “Store” se responsabiliza por todo o código que atribui ou obtém os dados dos elementos. A “Dispatcher” funciona como uma central de comunicação com a “Store” daquele elemento, comunicando-se através eventos que chamamos de “Actions”. Na prática a “View” envia uma “Actions” para retornar ou alterar o estado de um determinado elemento para a “Dispatcher” que, por sua vez, informa a camada “Store” sobre o determinado evento solicitado, que por fim atende a chamada e informa a “View”.
Referência: https://facebook.github.io/flux/
Biblioteca de componentes
Uma prática que vem ganhando bastante espaço no desenvolvimento front-end é a documentação de componentes. Essa metodologia consiste em criar uma documentação de todos os componentes reutilizáveis da aplicação com exemplos de exibição, aplicação e utilidade de seus parâmetros.
Documentando os componentes de uma aplicação garantimos a padronização do sistema e facilitamos o processo de testes de qualidade, pois nas documentações constam exemplos práticos de todos os elementos.
Como recomendação para tal prática, sugerimos a utilização do “Storybook”, uma biblioteca moderna e compatível com diversos frameworks.
Como a arquitetura de front-end é uma camada intermediária entre o hardware e o usuário final em arquitetura de software, é possível criar uma boa experiência aos usuários por meio de um site ou aplicação que seja responsiva e que funcione perfeitamente em diversas telas e dispositivos.
Investir e escolher a arquitetura front-end correta será capaz de suportar mudanças e melhorias contínuas e incrementais para o seu negócio.
Referências:
https://dev.to/xavortm/what-are-components-in-the-front-end-and-why-do-we-need-them-2o2p