{front-end}

Arquitetura Front-end

  • Monolito (React SPA)
  • Redux (maior custo de desenvolvimento)
  • Alto acoplamento de código
  • Muitas dependências
  • Código legado
  • Escalabilidade só por override (Craco JS)
  • Baixa cobertura de testes
  • SEO
  • Performance
  • Design system
  • Mobile first

Como estamos?

Futuro

# ARCHICTURE

Proposta da
Arquitetura Front-end

Arquitetura client-side escalável, distribuída em camadas, com o objetivo de promover uma arquitetura front-end que favoreça a reusabilidade de código, coesão, independência de tecnologia e testabilidade.

// Pensando na escalabilidade do projeto, sem trazer complicações 
// e Over engineering, pensei em trazer um modelo de arquitetura para 
// o frontend do boilerplate. Indo direto ao ponto, esse é o modelo:


app-ma
├── components  # Componentes globais de uso geral do projeto.
├── layout      # Wrappers padrões para componentes ou páginas.
├── hooks       # Hooks globais de uso geral do projeto.
├── contexts    # Contexts para gerenciamento de estado global do projeto.
├── modules     # Módulos. Um para cada página, com a lógica de negócio.
│   └─ example-module
│       ├──  index.js/ts  # Ponto de partida desse módulo.
│       ├──  hooks        # Hooks globais de uso exclusivo desse módulo.
│       ├──  components   # Componentes de uso exclusivo desse módulo.
│       ├──  service      # Funções e lógicas de utilização geral e genérica
│       └──  utils        # Componentes de uso exclusivo desse módulo.
├── pages       # Cada página associada com uma rota e um módulo.
├── services    # Lógica de comunicação com o backend.
├── shared      # Tudo que for compartilhável. Sendo configuração de temas, etc.
└── utils       # Funções e lógicas de utilização geral e genérica.
# PRESENTING ARCH

Arquitetura Front-end - Organização

Obs: Essa estrutura interna aos Módulos é opcional e pode ser criada mediante necessidade, precisando inicialmente só do index.js/ts

# ARCH DEPEDENCY RULE

Arquitetura - Regra de Dependência 

Modelo de regra de arquitetura limpa para o frontend que respeita a "depency rule", regra muito utilizada na maioria das arquiteturas existentes de software.

# MONOREPO

Monorepo
Legado & Novo

Uma proposta de solução em um monorepo que visa a coexistência do legado com o novo. Essa abordagem sugere a modularização do aplicativo e a evolução da base de código, sem a perda das páginas, componentes e funcionalidades já existentes.

  • Ferramenta de build
  • Modularização de apps
  • Desenvolvimento paralelo

  • Coexistência legado x novo

  • Compartilhamento dos comp. entre as apps

  • Reutilização de código de pacotes compartilhados
  • Cache local dos pacotes
  • Configurações de código (ESlint, TSconfig, etc)
  • Já suporta micro front-end
  • Cases (Boticário e Globo)
  • Velocidade de compilação (Rust)
  • Watch mais inteligente
  • Segurança nas dependências (publicas e privadas)

Turborepo - Vantagens

  • Requer download do codebase completo
  • Nem todos pacotes (npm) existentes vão funcionar com o Turborepo
  • Complexidade de configuração para devs com menor senioridade
  • O codebase pode ficar muito grande com o tempo
  • Dependências antigas podem não serem aceitas por questões de segurança e vulnerabilidade
  • O esforço de implementação com o legado pode ser alto

Turborepo - Desvantagens

TURBOREPO 

# TURBOREPO EXAMPLE
# MONOREPO

Multi-repo
Novo

Uma proposta de solução multi-repo pensando somente em uma nova app e uma nova proposta de arquitetura. Essa abordagem sugere a modularização do aplicativo, escalabilidade, sem o aproveitamento do que já foi desenvolvido, porém com todos os benefícios da proposta anterior.

  • Ferramenta de build muiito rápida
  • Typescript
  • Suporta SSR
  • Suporta micro frontends
  • Suporta Next.js
  • Gerenciamento de dependências automatizado
  • Monitoria de vulnerabilidades
  • Configurações que promovem a padronização do código e da app
  • Redução de erros
  • Aumenta a produtividade
  • Facilita escalabilidade
  • Controle de versões

Turbopack - Vantagens

  • Complexidade de instalação
  • Curva de aprendizado alta
  • Não suporta todas as dependências (npm)
  • Algumas soluções do framework são pagas (licença ou assinatura)
  • Necessita de um dev de maior senioridade na equipe

Turbopack - Desvantagens

# FRAMEWORKS

Next.JS ou Remix

  • Next.js é conhecido por sua renderização no lado do servidor (SSR) integrada e é uma escolha sólida para projetos que precisam de SSR de forma direta e eficiente.

 

  • Remix oferece suporte à renderização no servidor, semelhante às abordagens tradicionais, e enfatiza a flexibilidade e a personalização, sendo uma escolha para desenvolvedores que desejam maior controle sobre suas aplicações.

Made with Slides.com