A melhor arquitetura de front-end complexa: o que você precisa saber sobre design fatiado de recursos

Introdução

Os desenvolvedores front-end geralmente enfrentam problemas relacionados à arquitetura do aplicativo. Requer o uso de uma arquitetura que possa ser facilmente dimensionada e fornecer baixo acoplamento e alta coesão entre os módulos do aplicativo.

Este artigo discute a arquitetura Feature-Sliced Design, pois, na minha opinião, é a melhor entre as opções disponíveis. Também explora a ideia do FSD e os problemas que esta metodologia arquitetônica resolve.

Compararemos o FSD com arquiteturas clássicas e modulares e examinaremos seus prós e contras.

Em primeiro lugar, vamos distinguir três conceitos: camada, fatia e segmento.

Camadas

As camadas são diretórios de nível superior e o primeiro nível de decomposição do aplicativo. São limitadas em número – máximo de 7 camadas – e padronizadas, embora algumas delas sejam opcionais.

Atualmente, distinguem-se as seguintes camadas:

Cada camada tem sua própria zona de responsabilidade e é voltada para os negócios. Vamos considerar cada camada separadamente.

• app: é aqui que a lógica do aplicativo é inicializada. Provedores, roteadores, estilos globais, declarações de tipo global, etc. são definidos aqui. Ele serve como ponto de entrada para o aplicativo.

• processos: esta camada lida com processos que abrangem várias páginas, como registro em várias etapas. Esta camada é considerada obsoleta, mas ainda pode ser encontrada ocasionalmente. É uma camada opcional.

• páginas: esta camada inclui as páginas do aplicativo.

• widgets: são componentes de UI independentes usados nas páginas.

• recursos: esta camada lida com cenários de usuário e funcionalidades que agregam valor ao negócio. Por exemplo, curtir, escrever comentários, avaliar produtos, etc. É uma camada opcional.

• entidades: esta camada representa entidades comerciais. Essas entidades podem incluir usuários, avaliações, comentários, etc. É uma camada opcional.

• compartilhado: esta camada contém componentes e utilitários reutilizáveis que não estão vinculados a uma lógica de negócios específica. Inclui um kit de UI, configuração do Axios, configuração do aplicativo, auxiliares que não estão vinculados à lógica de negócios, etc.

Essas camadas ajudam a organizar a base de código e promovem uma arquitetura modular, sustentável e escalável.

Uma das principais características do Feature-Sliced Design é sua estrutura hierárquica. Nesta estrutura, as entidades não podem usar funcionalidades de recursos porque os recursos estão em posições superiores na hierarquia.

Da mesma forma, os recursos não podem usar componentes de widgets ou processos, pois as camadas acima só podem utilizar as camadas abaixo. Isso é feito para manter um fluxo linear direcionado apenas em uma direção. Quanto mais baixa uma camada estiver posicionada na hierarquia, mais arriscado será fazer alterações nela, pois é provável que ela seja usada em mais lugares no código. Por exemplo, o kit de UI na camada compartilhada é usado nos recursos, widgets e até mesmo nas camadas de página.

Fatias

Em cada uma das camadas, existem subdiretórios – fatias – o segundo nível de decomposição do aplicativo. Em fatias, a conexão não é com coisas abstratas, mas com entidades empresariais específicas. O principal objetivo das fatias é agrupar o código por seu valor.

Os nomes das fatias não são padronizados, pois são determinados diretamente pela área de negócio do projeto. Por exemplo, em uma galeria de fotos, pode haver seções como foto, álbum e galeria. Uma rede social exigiria fatias como postagens, usuários e feeds de notícias.

Fragmentos intimamente relacionados podem ser agrupados estruturalmente em um diretório, mas devem seguir as mesmas regras de isolamento que outras fatias - não deve haver acesso compartilhado ao código neste diretório.

Segmentos

Cada fatia consiste em segmentos. Os segmentos ajudam a dividir o código dentro de uma fatia com base em sua finalidade. Dependendo dos acordos da equipe, os segmentos podem mudar em composição e nomenclatura. Os seguintes segmentos são mais comumente usados:

• api - solicitações de servidor necessárias.

• UI - componentes de UI da fatia.

• modelo - Lógica de negócios, ou seja, interação com o estado. Por exemplo, ações e seletores.
• lib - funcionalidade auxiliar usada na fatia.

• config - configuração necessária do slice, mas o segmento de configuração raramente é encontrado.

• consts - constantes necessárias.

API pública

Cada fatia e segmento possui uma API pública. A API Pública é representada por um arquivo index.js ou index.ts, que permite extrair apenas a funcionalidade necessária da fatia ou segmento para o exterior e isolar funcionalidades desnecessárias. O arquivo de índice serve como ponto de entrada.

Regras para a API pública:

• As fatias e os segmentos do aplicativo usam apenas a funcionalidade e os componentes da fatia definidos no arquivo de índice da API Pública.

• A parte interna da fatia ou segmento que não está definida na API Pública é considerada isolada e aberta apenas para acesso dentro da própria fatia ou segmento.

A API Pública simplifica o trabalho com importação e exportação, portanto, ao fazer alterações no aplicativo, não há necessidade de alterar as importações em todo o código.

Aprofundando-se na arquitetura

Abstração e lógica de negócios

Quanto mais alta a camada, mais ela está vinculada ao nó de negócios específico e mais lógica de negócios contém. Quanto mais baixa a camada, mais abstrações, reutilização e falta de autonomia na camada.

Como o FSD resolve o problema?

Uma das tarefas do Feature-Sliced Design é obter acoplamento fraco e alta coesão. É importante entender como o FSD alcança esse resultado.

Na OOP, esses problemas há muito são resolvidos por meio de conceitos como polimorfismo , encapsulamento , herança e abstração . Esses conceitos garantem isolamento, reutilização e versatilidade do código, onde resultados diferentes são obtidos dependendo de como um componente ou funcionalidade é utilizado.

O Feature-Sliced Design ajuda a aplicar esses princípios no frontend.

Abstração e polimorfismo são alcançados por meio de camadas. Como as camadas inferiores são abstratas, elas podem ser reutilizadas em camadas superiores e, dependendo das condições, um componente ou funcionalidade pode funcionar de maneira diferente com base nos parâmetros ou adereços especificados.

O encapsulamento é conseguido através da API Pública, que isola o que não é necessário do exterior em fatias e segmentos. O acesso aos segmentos internos de uma fatia é restrito e a API Pública é a única maneira de acessar funcionalidades e componentes de uma fatia ou segmento.

A herança também é obtida por meio de camadas, pois as camadas superiores podem reutilizar as camadas inferiores.

Comparação com a arquitetura clássica

Acredito que você já se deparou com arquitetura clássica muitas vezes. A maioria dos autores utiliza-o em artigos educacionais e vídeos do YouTube devido à sua simplicidade. Não existe um padrão específico para arquitetura clássica. No entanto, muitas vezes você pode ver o seguinte formato:

A arquitetura clássica tem desvantagens visíveis. A maior delas é que o projeto se torna difícil de manter devido às conexões implícitas entre os componentes e à confusão de módulos. As desvantagens da arquitetura clássica tornam-se mais aparentes com o tempo. Quanto mais o projeto evolui, mais a arquitetura do aplicativo se torna uma bagunça difícil de desvendar.

A arquitetura clássica é adequada para pequenos projetos sem manutenção contínua ou projetos de estimação.

O Feature-Sliced Design, graças aos seus conceitos e padrões, evita os problemas da arquitetura clássica.

No entanto, o nível de compreensão e habilidades dos desenvolvedores que trabalham com FSD deve ser maior do que quando trabalham com arquitetura clássica. Normalmente, os desenvolvedores com menos de 2 anos de experiência nunca ouviram falar de FSD.

No entanto, ao trabalhar com Feature-Sliced Design, os problemas precisam ser resolvidos “agora” e não “mais tarde”. Problemas no código e desvios dos conceitos tornam-se imediatamente aparentes

Comparação com arquitetura modular simples

A arquitetura modular simples tem várias desvantagens:

• Às vezes não está claro onde colocar funcionalidade em módulos ou componentes.

• Dificuldades em utilizar módulos dentro de outro módulo.

• Problemas com o armazenamento de entidades comerciais.

• Dependências implícitas em funções globais, levando a uma estrutura emaranhada.

Parece que em qualquer projeto complexo ou moderadamente complexo, o Feature-Sliced Design deve ser preferido à arquitetura modular simples. O FSD resolve muitos problemas arquitetônicos fundamentais e tem poucas desvantagens.

Em termos de simplicidade e velocidade de desenvolvimento, uma arquitetura modular simples pode ter uma vantagem sobre o FSD. Se for necessário um MVP ou um projeto de curta duração estiver sendo desenvolvido, uma arquitetura modular simples pode ser mais adequada que o FSD. Mas, em qualquer outro caso, um design com fatias de recursos parece preferível.

O potencial do design fatiado por recursos

FSD é uma metodologia arquitetônica jovem. No entanto, já está sendo utilizado por muitos bancos, fintech, B2B, empresas de comércio eletrônico e outras. Aqui está um link para o problema do GitHub com uma lista de empresas: GitHub Issue .

O repositório GitHub com a documentação oficial do FSD tinha mais de 1,1 mil estrelas no momento da publicação deste artigo. A documentação está sendo ativamente expandida, e a equipe de desenvolvimento do FSD e a comunidade no Telegram e Discord estão disponíveis 24 horas por dia, 7 dias por semana, para ajudar as pessoas com questões relacionadas à arquitetura.

O potencial desta arquitetura é altamente valorizado e seu uso é amplamente difundido entre grandes empresas em todo o mundo. Com a adoção adequada, o FSD tem potencial para se tornar a solução arquitetônica dominante na área de desenvolvimento front-end.

Vantagens e desvantagens da arquitetura

Vantagens

• Os componentes da arquitetura podem ser facilmente substituídos, adicionados ou removidos

• Padronização da arquitetura

• Escalabilidade

• A metodologia é independente da pilha de desenvolvimento.

• Conexões controladas e explícitas entre módulos sem efeitos colaterais inesperados.

• Metodologia arquitetônica voltada para negócios.

Desvantagens

• Uma barreira de entrada mais elevada em comparação com muitas outras soluções arquitetónicas.

• Requer consciência, cultura de equipe e aderência aos conceitos.

• Desafios e questões precisam ser abordados imediatamente, e não mais tarde. Problemas de código e desvios de conceitos são imediatamente visíveis. No entanto, isso também pode ser visto como uma vantagem.

Conclusão

Feature-Sliced Design é uma descoberta interessante e valiosa que os desenvolvedores front-end devem conhecer e ser capazes de usar. O FSD pode fornecer às equipes uma arquitetura e cultura de desenvolvimento flexível, padronizada e escalonável. Porém, utilizar os aspectos positivos da metodologia requer conhecimento, consciência e disciplina da equipe.

O FSD se destaca entre outras arquiteturas devido à sua clara orientação de negócios, definição de entidade, composição funcional e composição de componentes da aplicação.

Você também pode explorar de forma independente exemplos de uso de FSD em projetos e a documentação oficial do Feature-Sliced Design:

Documentação Oficial

Exemplo. Cliente GitHub

Exemplo. Loja de tênis e calçados Nike

Exemplo. Sudoku

Este post pode ser longo, mas espero que você tenha aprendido algo novo. Agradeço que você tenha terminado de ler esta postagem.

Se você tiver alguma opinião ou dúvida, fique à vontade para deixar um comentário!

Também publicado aqui