Pular para o conteúdo principal
Interface Atlas
5 min de leitura
Guia

O que a Arquitetura Frontend Realmente É (e o que Não É)

Arquitetura frontend é a estrutura intencional de limites na sua base de código. Não é o nome do framework que você instalou via npm.

Publicado
Por Interface Atlas Team

Conteúdo

O erro de diagnóstico mais comum no desenvolvimento web moderno soa assim: “Nossa arquitetura frontend é React com Tailwind.”

React é uma biblioteca de UI. Tailwind é um sistema de estilo. Nenhum dos dois é uma arquitetura.

Se você acredita que seu framework é sua arquitetura, você deixará de tomar decisões estruturais. Você deixará o roteador de arquivos padrão do framework ditar o fluxo dos seus dados. Você deixará seus componentes buscarem seus próprios dados, gerenciarem sua própria lógica de domínio e lidarem com seu próprio estilo, tudo no mesmo arquivo. Isso não é arquitetura. É uma bolha indomável de complexidade acidental esperando para ossificar.

Arquitetura Frontend é o design intencional de limites.

Arquitetura como um Sistema de Limites

A boa arquitetura permite que as equipes alterem uma parte de um sistema sem quebrar todo o resto. Ela faz isso impondo limites.

O Limite do Componente (Separação de Preocupações)

A clássica Separação de Preocupações significava dividir HTML, CSS e JavaScript em arquivos separados. O desenvolvimento moderno orientado a componentes mudou isso: agora agrupamos o código por recurso, não por tipo de arquivo.

No entanto, a preocupação ainda existe. Um componente de UI não deve montar URLs de API, analisar JSON bruto em objetos de domínio, impor regras de negócios e renderizar marcação tudo de uma vez.

graph TD
    subgraph A Bolha (Arquitetura Acidental)
        B1[Componente Botão] -->|Busca Dados| B2(Resposta Bruta da Rede)
        B1 -->|Analisa| B3(Lógica de Domínio)
        B1 -->|Renderiza| B4(UI)
    end

    subgraph O Limite (Arquitetura Disciplinada)
        D1[Camada de Dados] -->|Normaliza| D2[Camada de Domínio]
        D2 -->|Passa Props| P1[Camada de Apresentação]
    end

Um exemplo de Arquitetura Acidental: Um componente React UserProfile chama fetch(), verifica manualmente se user.age > 18 e então retorna um selo vermelho se a verificação falhar. Se a regra de idade mudar para 21, você terá que caçar todos os componentes de UI que verificam manualmente a idade. Um exemplo de Disciplina de Limite: Um módulo de domínio User dedicado exporta uma função canDrinkAlcohol(user). O componente UserProfile importa essa função. A UI sabe como renderizar o selo vermelho; o módulo de domínio conhece as regras.

O Limite de Estado

O estado deve ter o escopo mais restrito possível.

  1. Estado Local: Preocupações efêmeras de UI. Este dropdown está aberto? O que está digitado neste input? (Pertence ao componente).
  2. Estado de Recurso: Estado compartilhado dentro de um domínio de recurso específico. (Pertence a um provedor de contexto ou store com escopo de recurso).
  3. Estado Global: Estado que o aplicativo inteiro precisa saber, como o usuário logado no momento ou o tema selecionado. (Pertence a uma store global).

O Modo de Falha: Colocar um booleano como isDropdownOpen em uma store Redux global. Isso acopla um detalhe microscópico da UI à arquitetura global, forçando re-renderizações desnecessárias.

O Limite de Renderização

Nem todos os pixels são criados iguais. A arquitetura exige decidir onde e quando o código se transforma em HTML.

Se você tratar um site de marketing e um painel SaaS complexo da mesma maneira, você está falhando na arquitetura. Um site de marketing exige uma Estratégia de Renderização estática para SEO e velocidade. Um painel SaaS exige interatividade do lado do cliente. Escolher o limite de renderização errado impõe penalidades permanentes de desempenho.

Os Quatro Modos de Arquitetura

Diferentes formas de produtos exigem sistemas de limites inteiramente diferentes.

1. A Publicação de Conteúdo (ex: Interface Atlas)

  • Limite Principal: O Modelo de Conteúdo (Arquitetura da Informação).
  • Estado: Mínimo ou inexistente.
  • Renderização: HTML estático com ilhas interativas seletivas.
  • Foco da Arquitetura: Garantir que o conteúdo seja desacoplado dos componentes de layout para que possa ser consultado e reutilizado.

2. A Aplicação de Página Única (SPA)

  • Limite Principal: Estado do lado do cliente e roteamento.
  • Estado: Caches de cliente complexos e altamente normalizados.
  • Renderização: CSR ou SSR de página inteira/Hidratação.
  • Foco da Arquitetura: Gerenciar a sincronização entre o banco de dados do servidor e a memória do lado do cliente.

3. O Sistema de Design (Design System)

  • Limite Principal: O contrato de API dos componentes de UI.
  • Estado: Estado de UI local estritamente controlado; completamente agnóstico aos dados de domínio.
  • Renderização: Deve suportar múltiplos ambientes (React, Vue, Web Components).
  • Foco da Arquitetura: Consistência, acessibilidade e prevenção de mudanças drásticas (breaking changes) para as equipes consumidoras.

Heurística Final

O teste da sua arquitetura frontend não é se ela usa o framework mais recente. O teste é o que acontece quando os requisitos mudam.

Se alterar a estrutura de dados do seu backend exige reescrever seus componentes de UI, seus limites falharam. A arquitetura é a disciplina de proteger a UI do banco de dados e proteger o banco de dados da UI.

Guias e Termos Relacionados

Para uma exploração mais profunda, veja: