# Atualização e Otimização



# Tempo de loading e tamanho de bundle do Console

**Tamanho do Bundle (Stat Size):** ~22.6 MB (Tamanho antes da minificação).

**Tamanho do Download (Network):** ~16 MB.

**Ambiente de Build:** `react-scripts` v1.1.5 (baseado em Webpack 3) e React v16.3.2.

#### 1. Diagnóstico

A versão 1.1.5 do `react-scripts` utiliza o **Webpack 3**, que possui limitações técnicas severas quanto ao *Tree-Shaking* (remoção de código morto).

Diferente de versões modernas, o Webpack 3 frequentemente inclui o conteúdo integral de bibliotecas externas no bundle final, mesmo quando apenas uma função ou componente é importado no código. Isso gerou um acúmulo de código não utilizado que é enviado para o cliente.

#### 2. Redundâncias Identificadas

Estão em uso várias *libs* redundantes no projeto, agravando o tamanho do bundle.

<table data-path-to-node="10" id="bkmrk-categoria-biblioteca"><thead><tr><td>**Categoria**</td><td>**Bibliotecas Conflitantes**</td><td>**Ação Recomendada**</td></tr></thead><tbody><tr><td><span data-path-to-node="10,1,0,0">**Interface (UI)**</span></td><td><span data-path-to-node="10,1,1,0">`antd`, `semantic-ui-react`, `rsuite`, `bootstrap`</span></td><td><span data-path-to-node="10,1,2,0">Padronizar o uso do **Ant Design** e remover as demais bibliotecas de UI e seus arquivos CSS.</span></td></tr><tr><td><span data-path-to-node="10,2,0,0">**Datas**</span></td><td><span data-path-to-node="10,2,1,0">`moment` (c/ `timezone`), `luxon`, `date-fns`</span></td><td><span data-path-to-node="10,2,2,0">Manter apenas **date-fns**. Remover `moment` reduzirá drasticamente o bundle.</span></td></tr><tr><td><span data-path-to-node="10,3,0,0">**Processamento**</span></td><td><span data-path-to-node="10,3,1,0">`xlsx`, `js2excel`, `react-xls`</span></td><td><span data-path-to-node="10,3,2,0">Carregar bibliotecas de planilhas apenas sob demanda (*Lazy Loading*).</span></td></tr><tr><td><span data-path-to-node="10,4,0,0">**Utilitários**</span></td><td><span data-path-to-node="10,4,1,0">`lodash` (importação completa)</span></td><td><span data-path-to-node="10,4,2,0">Alterar importações para métodos específicos ou usar `babel-plugin-lodash`.</span></td></tr></tbody></table>

#### 3. Estratégias de Mitigação

Medida A: Habilitação de Compressão (Gzip/Brotli)

Configuração do Nginx para servir arquivos estáticos comprimidos.

- **Impacto:** Redução estimada do download de 16 MB para ~4 MB.
- **Complexidade:** Baixa (Infraestrutura).
- **Observação:** Resolve a transferência, mas não o tempo de processamento (*parse*) do JS.

Medida B: Implementação de Code Splitting (Lazy Loading)

Carregamento assíncrono para módulos pesados não essenciais no boot (ex: react-qr-scanner, xlsx).

- **Implementação:** Utilizar `React.lazy` e `Suspense`.
- **Impacto:** Redução estimada de 5 MB a 8 MB no carregamento inicial.
- **Complexidade:** Média.

Medida C: Higienização de Dependências

Remoção manual das bibliotecas listadas e refatoração.

- **Impacto:** Redução do Stat Size.
- **Complexidade:** Alta.

<table data-path-to-node="19" id="bkmrk-estrat%C3%A9gia-vantagens"><thead><tr><td>**Estratégia**</td><td>**Vantagens**</td><td>**Desvantagens**</td><td>**Esforço**</td></tr></thead><tbody><tr><td><span data-path-to-node="19,1,0,0">**Compressão (Gzip)**</span></td><td><span data-path-to-node="19,1,1,0">Resultado imediato; Baixo risco.</span></td><td><span data-path-to-node="19,1,2,0">Não resolve CPU client-side.</span></td><td><span data-path-to-node="19,1,3,0">Baixo</span></td></tr><tr><td><span data-path-to-node="19,2,0,0">**Lazy Loading**</span></td><td><span data-path-to-node="19,2,1,0">Remove código do boot; Melhora renderização.</span></td><td><span data-path-to-node="19,2,2,0">Pequeno delay na interação sob demanda.</span></td><td><span data-path-to-node="19,2,3,0">Médio</span></td></tr><tr><td><span data-path-to-node="19,3,0,0">**Remoção de Libs**</span></td><td><span data-path-to-node="19,3,1,0">Código mais limpo e seguro.</span></td><td><span data-path-to-node="19,3,2,0">Alto risco de quebra; Custo alto de dev.</span></td><td><span data-path-to-node="19,3,3,0">Alto</span></td></tr></tbody></table>

#### 4. Resultados do Teste de Compactação

Testes realizados em 17/12/25 para evidenciar o ganho de performance obtido com a ativação da compressão Gzip no servidor Nginx.

<table data-path-to-node="23" id="bkmrk-m%C3%A9trica-avaliada-cen"><thead><tr><td>**Métrica Avaliada**</td><td>**Cenário A: Sem Compressão (Atual)**</td><td>**Cenário B: Com Compressão (Otimizado)**</td><td>**Ganho Obtido**</td></tr></thead><tbody><tr><td><span data-path-to-node="23,1,0,0">**Tamanho do Arquivo**</span></td><td><span data-path-to-node="23,1,1,0">17 MB</span></td><td><span data-path-to-node="23,1,2,0">**3,8 MB**</span></td><td><span data-path-to-node="23,1,3,0">**📉 -77,6% (Redução de peso)**</span></td></tr><tr><td><span data-path-to-node="23,2,0,0">**Tempo de Download**</span></td><td><span data-path-to-node="23,2,1,0">2 min 46 s</span></td><td><span data-path-to-node="23,2,2,0">**1 min 15 s**</span></td><td><span data-path-to-node="23,2,3,0">**🚀 2,2x Mais Rápido**</span></td></tr></tbody></table>

####   

# Plano de Modernização do Console

A atualização do frontend do Console é uma tarefa complexa que envolve toda a equipe ligada ao front e exige um planejamento estratégico de médio prazo. Este documento detalha o diagnóstico atual e propõe soluções definitivas para os **gargalos de performance e manutenção**, focando na eliminação de redundâncias, simplificação do código e, principalmente, na desestruturação de funcionalidades em aplicações dedicadas.

#### 1. Diagnóstico

O Console opera atualmente como um projeto monolítico composto por **532 diretórios** e **1.108 arquivos**, distribuídos em uma intrincada rede de componentes (mapa completo em anexo). Tamanha complexidade impede a modernização da plataforma, dificultando a manutenção e a implementação de *novas features*.

[![complexity-heatmap.png](https://wiki.oystr.com.br/uploads/images/gallery/2026-02/scaled-1680-/nXPcode-generated-image.png)](https://wiki.oystr.com.br/uploads/images/gallery/2026-02/nXPcode-generated-image.png)

A análise de complexidade ciclomática via ESLint (gráfico em anexo) aponta o **Oystr Controladoria (Intimations)** como o módulo mais crítico, o que se justifica por sua dimensão. A separação deste e de outros módulos em projetos dedicados é essencial para a atualização de dependências e a saúde do código. Além disso, o tempo de *loading* é severamente impactado pelo excesso de bibliotecas redundantes.

O redesenho da arquitetura é uma necessidade imprescindível; a inação tornará os problemas críticos. É necessário não apenas corrigir erros, mas reformar a arquitetura para impedir sua recorrência. O principal desafio é garantir que o código novo opere simultaneamente ao legado durante a migração.

#### 2. Estratégias de atualização

Em testes realizados em 2023, verificamos que o **TurboRepo** é competente para gerenciar micro-frontends. No entanto, sua implementação exigiria uma ruptura total com a arquitetura atual, visto que ele apresenta incompatibilidades com a versão do React utilizada no legado.

Diante disso, a abordagem utilizando **Astro** + **Nginx** mostra-se superior ao Module Federation puro para o nosso cenário:

1. **Compatibilidade:** O Astro permite integração com versões antigas do React sem quebrar o funcionamento atual.
2. **Performance:** Oferece *Server Islands* para renderizar componentes de forma isolada e performática.
3. **Segurança:** Permite configurar o Nginx para servir a versão nova ou a legada baseada na rota, possibilitando uma migração gradual e segura.

<table data-path-to-node="2" id="bkmrk-crit%C3%A9rio-astro-%2B-ngi"><thead><tr><td>**Critério**</td><td>**Astro + Nginx (Multi-SPA)**</td><td>**Module Federation + Turborepo (Micro-frontends Puro)**</td></tr></thead><tbody><tr><td><span data-path-to-node="2,1,0,0">**Integração com Legado**</span></td><td><span data-path-to-node="2,1,1,0">**Imediata e Segura.** O Nginx serve o legado como ele é hoje. Não exige refatoração.</span></td><td><span data-path-to-node="2,1,2,0">**Dolorosa.** Exige alinhar versões do React/Webpack do legado com o novo app para não quebrar.</span></td></tr><tr><td><span data-path-to-node="2,2,0,0">**Complexidade de Config**</span></td><td><span data-path-to-node="2,2,1,0">**Baixa.** Baseado em rotas de URL e arquivos estáticos simples.</span></td><td><span data-path-to-node="2,2,2,0">**Altíssima.** Requer configuração avançada de Webpack, `shared modules` e resolução de singletons.</span></td></tr><tr><td><span data-path-to-node="2,3,0,0">**Isolamento de Falhas**</span></td><td><span data-path-to-node="2,3,1,0">**Total.** Se o módulo "Pautas" quebrar, o "Monitoramento" continua funcionando.</span></td><td><span data-path-to-node="2,3,2,0">**Parcial.** Um erro de dependência compartilhada ou no Shell pode derrubar a tela toda (Tela Branca).</span></td></tr><tr><td><span data-path-to-node="2,4,0,0">**Navegação (UX)**</span></td><td><span data-path-to-node="2,4,1,0">**MPA (Multi-Page).** Ocorre um *refresh* rápido ao trocar de módulo. Astro suaviza com *View Transitions*.</span></td><td><span data-path-to-node="2,4,2,0">**SPA (Single-Page).** Navegação fluida sem refresh, preservando estado em memória.</span></td></tr><tr><td><span data-path-to-node="2,5,0,0">**Compartilhamento de Estado**</span></td><td><span data-path-to-node="2,5,1,0">**Via URL/Cookies.** Dados complexos precisam ser persistidos no *localStorage* ou Backend.</span></td><td><span data-path-to-node="2,5,2,0">**Via Context/Props.** Fácil compartilhar estado global (ex: Tema, Usuário) em memória.</span></td></tr><tr><td><span data-path-to-node="2,6,0,0">**Deploy**</span></td><td><span data-path-to-node="2,6,1,0">**Independente.** Cada app tem seu build. O Nginx apenas aponta para a pasta nova.</span></td><td><span data-path-to-node="2,6,2,0">**Coordenado.** É preciso garantir que o Shell e os Remotes estejam compatíveis.</span></td></tr><tr><td><span data-path-to-node="2,7,0,0">**Curva de Aprendizado**</span></td><td><span data-path-to-node="2,7,1,0">**Rápida.** Desenvolvedores lidam com conceitos padrão da Web (Links, HTML, HTTP).</span></td><td><span data-path-to-node="2,7,2,0">**Lenta.** A equipe precisa entender profundamente como o Bundler (Webpack/Vite) funciona.</span></td></tr><tr><td><span data-path-to-node="2,8,0,0">**Risco para Equipe Pequena**</span></td><td><span data-path-to-node="2,8,1,0">**Baixo.** Permite focar em código de produto e não em infraestrutura de frontend.</span></td><td><span data-path-to-node="2,8,2,0">**Alto.** Pode consumir semanas da equipe apenas "configurando o ambiente" em vez de entregar features.</span></td></tr></tbody></table>

#### 3. Testes e próximos passos

A validação do ambiente é crucial. Áreas isoladas, como os componentes de UI ou o app **Oystr 360**, são candidatos ideais para o projeto piloto.

**Plano de Ação:**

1. **Criação do Repositório:** Iniciar um novo repositório para a nova versão do Console (baseada em Astro/Vite).
2. **Manutenção do Legado:** Garantir que o código atual permaneça inalterado e funcional via Nginx até a conclusão da migração.
3. **Prova de Conceito (PoC):** Testar as bibliotecas e ferramentas selecionadas para validar a aplicabilidade e mapear limitações técnicas.

#### 4. Principais problemas

Existem diversos problemas no Console que em parte poderão ser resolvidos com a atualização proposta, mas que vão além disso. Algumas dessas questões [já foram abordadas mais extensivamente](https://wiki.oystr.com.br/books/interno-frontend/page/tempo-de-loading-e-tamanho-de-bundle-do-console).

1. **Redundância de dependências:** Remover libs não utilizadas e redundantes. Assim como códigos legados.
2. **Converter componentes de** **classe:** Grande parte do Console ainda usa componentes de classe, além de outras tecnologias obsoletas. Durante a atualização do Console é importante converte-los para componentes funcionais e refatora-los.
3. **Componentes redundantes e não padronizados:** Além das libs diferentes, existem muitos casos de componentes com os mesmos use cases, mas com diferentes funções e estilos. Além das conversões desnecessárias e complexificação excessiva, os estilos diferentes em várias telas atrapalham a identidade e uniformidade dos apps.
4. **Componentes complexos e verbosos:** Muitos componentes poderiam ser simplificados e desestruturados para melhorar legibilidade e manutenção.
5. **Falta CI/CD:** O fluxo de deploy ainda é manual, outra atualização importante é dockerizar o Console, desenvolver testes automatizados e implementar pipelines integrados ao Bitbucket que agilizarão o desenvolvimento e deploy.
6. **Falta typescript e react query:** Diversas tecnologias e libs que são essenciais para o desenvolvimento não são compatíveis com o React 16. Implementando typescript resolveríamos os erros de tipo e evitaríamos bugs e crashes que afetam os usuários e custam tempo de desenvolvimento. Já o react query permitiria simplificar grandemente as chamadas de requisições e gerenciamento de estado.
7. **Erros e warnings:** O console possui centenas de erros e warnings de diferentes complexidades que ainda não tivemos tempo de atuar. É um ponto de atenção para gradualmente resolvermos conforme refatoramos e atualizamos.