Skip to main content

Arquitetura Front-end

· 11 min read
Bruno Carneiro
Bruno Carneiro
Fundador da @TautornTech

Este é um artigo que quero escrever há muito tempo mas só enrolo... Hoje acordei às 5h e, por alguma força oculta da natureza, sentei em frente o PC pra poder escreve algo misterioso que sai da minha cabeça.

Sem mais enrolação, o objetivo aqui é descrever algumas arquiteturas Front-end que é um tema complexo e estranhamente abordado.

Neste artigo vou abordar um exemplo de arquitetura e armadilhas por não seguir um padrão bem definido. O que trago é uma visão do desenvoveldor de software e coisas que ele deve se preocupar para mitigar problemas futuros, para ele e para a empresa.

Arquitetura de sofware é sobre o que é importante para o negócio.


Antes de mais nada, quero deixar aqui um Twitter (eu sei que agora chama X, mas é um nome horrível e não da pra entender nada, parece outro site...) que encontrei nesse artigo aqui que achei fantástico.

D-e-f-i-n-i-t-i-v-a-m-e-n-t-e estrutura de pastas NÃO é arquitetura de software, nem ontem, nem hoje e nem vai ser amanhã. Falar que organizou algumas pastas e que taí a sua arquitetura então você está redondamente enganado.

MAS, de fato, tem correlação, estrutura de pastas é algo muito importante porque diz muito da - organização do seu sistema - e da relação de estruturas, regras, patterns. Cria escopo e lógica em diferentes níveis para de fato ter uma estrutura decente para desenvolvimento, encontrar arquivos e evoluir as coisas.

Essa sem dúvida é uma das falhas mais comuns, a primeira é não saber que diabos de arquitetura usar (quando não mistura várias por puro hipe) e a segunda pra mim é organizar de forma mal elaborada o projeto.

Já peguei diversos sistemas com arquiteturas bem definidas - no papel - mas que na prática escalavam de forma desorganizada. O que mais se tem na internet é aquele Clean Architecture com poucos casos onde o sistema começa a escalar e vai tudo pro ralo porque não foi pensado em escala (o time) e muito menos entenderam de fato o que cada cadamada proposta faz.

Aqui não é crítica ao Clean Architcture (não sou maluco disso e o que posso falar do Uncle Bob, simplesmente um dos maiores gênios da programação). A crítica aqui é pra quem usa e não sabe como usar. O formato proposto funciona muito bem, quando bem aplicado.

Mas pra ir direto ao ponto, um dos maiores problemas que vejo é a falta de conhecimento sobre o que cada arquitetura propõe como solução, como ela é organizada e se você/time/projeto de fato precisam dela.

Que tal um microservice para uma página de login? hehehe

Mas onde entra o Front-end? Um problema que vejo é a falta de conhecimento nas arquiteturas existentes para resolver problemas no Front-end e a capacidade de escala de bibliotecas (todo dia tem uma nova resolvendo algo de forma milagrosa).

Conhecer arquitetura de software - no geral - é a base e conhecer pra tudo. As boas e más decisões que você faz afetam não só você, mas seu time, projeto, usuários, pense nisso antes de adicionar a nova lib da moda.

O que é uma arquitetura de software?​

Bom, como já disse, arquitetura não é sobre organização de pastas (apesar de ser algo muito importante). É sobre decisões importentes que você toma no início do projeto.

“Architecture is about the important stuff. Whatever that is”. Martin Fowler

Sempre que me pergutam sobre arquitetura reocmendo este artigo aqui, jovem gafanhoto: Martin Fowler

Tenho outro artigo que escrevi, de forma geral, sobre arquitetura-de-software.

::: info Boa parte do que eu poderia falar aqui está no meu artigo que mensionei anteriormente e pra não ficar algo repetitivo vou focar no Front-end. Sobre o que de fato acredito que seja um arquitetura, o que não é e outros aspectos recomendo que anteriormente leiam o meu artigo. :::

Como pensar em uma arquitetura?​

Sempre que vou iniciar uma arquitetura de software eu gosto de questionar as necessidades do produto/projeto que estou desenvolvendo. Essa é a base das necessidades do projeto, o contrário é apenas um amontado de tecnologia e gosto próprio.

Aqui alguns pontos importantes para serem questionados:

  • Qual é o público que vai usar a aplicação?
  • Quais são as prioridades do negócio?
  • É necessário que seja mobile-first?
  • Precisa rodar offline?
  • Já existem outras apis que precisamos conectar? Imagino cenário que é preciso orquestrar requisições de vários módulos
  • O Front-end é responsável por múltiplas chamadas? Esse ponto casa com o anterior, aqui é pra entender se é necessário até mesmo uma camada de Edge Api.
  • Qual é o nível de otimização? Imagina que é preciso rodar em dispositivos de baixo desempenho então otimização (que é sempre importante) pode ser um dos pontos chaves.
  • Custo e Budget disponíveis. Esse é bem importante porque pode limitar acesso à algumas tecnologias, sendo necessário desenvolvimento interno ou utilização de recursos mais baratos ou similares. Nem toda empresa vai conseguir pagar uma plataforma de observabilidade que custe US$ 10k, por exemplo.
  • Já existem módulos prontos do FE e que precisam ser acoplados ao novo projeto mantendo a evolução separada? Pense em pacotes npm internos ou até mesmo microfrontend.
  • Tráfego de usuários (pensando em tempo de carregamento de página e módulos, bem como feedback para o usuário).
  • Pensando ainda na anterior, isso pode levar há um outro questionamento. A plataforma precisa funcionar de foma síncrona e assíncrona? É muito comum demandas vierem com esses requisitos mas podem existir cenários que na largada já precisamos pensar neste caso.
  • É necessário um sistema de cacheamento no Client?
  • É necessário um sistema de Storage no Client?
  • Flow de desenvolvimento e distribuição das release
  • Modelo de testes (unitário, integrado, e2e).
  • CI/CD
  • Delivery e rollback das release
  • Observabilidade
  • Quantidade de pessoas que vão trabalhar no projeto. Podem existir times pequenos e até mesmo mistos trabalhando na mesma solução e isso impacta diretamente nas entregas e evolução do sistema.
  • É necessário um design system? (cuidado com este item, pode parecer interessante mas também pode virar uma grande dor de cabeça)
  • Desenvolvimento de guide-line da equipe.
  • Nível de segurança
  • Escalabilidade
  • Reutilização
  • Existe algum sistema de notificação?
  • É necessário algum BFF ou sistema de orquestração?
  • Documentação
  • Dependência com terceiros
info

Já ouviu falar de Requisitos funcionais e não funcionais? [versão em inglês] Conhecer sobre requisitos funcionais e não funcionais são uma forma de guiar pelos tópicos acima mensionados.

Existem alguns outros pontos, mas a ideia principal aqui é ESTEJA ALINHADO COM O NEGÓCIO. E o que listei acima são válidos para um Software, não estou pensando em Front-end ou Back-end especificamente, mas um Software onde existem camadas e vários pontos a serem pensados.

Dito isto, é normal que nem tudo o que é desejado pelo time técnico vai ser possível de implantar.

Problemas que podem ocorrer​

Como você pode ter perceibo é basicamente um levantamento de requisitos não funcionais. É claro que o foco é no sistema (requisitos funcionais) mas sabendo disso temos o que a arquitetura ter.

Listei aqui vários itens - e essa lista pode aumentar - que são muito importantes, mas que não necessariamente precisam estar na lagada. Muitos deles não deveriam existir inicialmente porque pode ocorrer o problema conhecido como overengineering. Que é basicamente o excesso de tecnologia pra resolver um problema específico sendo que poderia ser algo mais simples.

Imagina criar uma bazua pra matar uma formiga. Não faz o menor sentido. Mas isso ocorre com frequência 🐛

Um exemplo clássico, sistema ainda no MVP, o time nem sabe se vai escalar ou não, se terá usuários. Mas foi criado um sistema com microserviços, microfrontend, com vários design patterns se sobrescrevendo. Clean Architecture misturado com Hexagonal e por aí vai...

No Front-End existe Relay com sistema de Storage pra controle de página e abas, componentes criados com Atomic Design e uma estrutura que lembra NextJS com centenas de custom hooks espalhados, um pra cada chamada de API.

O caos total.

Criando assim um MVP lento, caro e com poucos testes para saber se de fato tem market fit. Somente após isso é que o time deveria levantar os requisitos pra de fato atender as necessidades do sistema.

Arquitetura Front-end​

Certo, mas devido a vários desses pontos levantados como devo construir a arquitetura Front-end e quais existem?

Vou listar algumas:

Arquiteturas Baseadas em Componentes​

A maioria dos frameworks modernos (React, Vue, Angular, Svelte) adota esse modelo:

  • Atomic Design: Organização de componentes em átomos, moléculas, organismos, templates e páginas
  • Design System: Sistema unificado de componentes, tokens e padrões
  • Bibliotecas de Componentes: Coleções de componentes reutilizáveis e consistentes

Arquiteturas de Fluxo de Dados​

  • Flux/Redux: Store centralizada, actions e reducers
  • MVC/MVVM: Separação entre modelo, visão e controle/view-model
  • Clean Architecture: Separação por camadas de responsabilidade
  • Hexagonal/Ports & Adapters: Isolamento do Core da aplicação
  • Feature Sliced Design (FSD): Uma metodologia de arquitetura para projetos front-end que organiza o código em camadas (slices) baseadas em características de negócio (features).
  • Signals (Angular, Solid, Vue): Sistema reativo baseado em primitivos observáveis
  • Context API (React): Alternativa leve ao Redux para gerenciamento de estado
  • Zustand/Jotai/Recoil: Bibliotecas de estado que oferecem abordagens mais simples
  • Event-Driven Architecture: Baseada em eventos e listeners para comunicação entre componentes

Arquiteturas de Escala​

  • Micro-frontends: Divisão do front-end em aplicações independentes
  • Module Federation: Compartilhamento de código em tempo de execução
  • Monorepos: Organização de múltiplos pacotes em um único repositório
  • Jamstack: Combina JavaScript, APIs e Markup pré-renderizado para melhor performance

Escolher a arquitetura adequada depende do tamanho, complexidade e requisitos da sua aplicação.

Aqui acabou aparecendo um emaranhado de arquiteturas e formas de montar os projetos e como dei uma breve explicacação de cada com certeza as coisas podem ter ficado mais confusas. Mas eu quis trazer a diversidade e organizações de projeto, é necessário entendimento de cada uma para saber qual é a mais adequada para cada projeto.

Mesmo assim, algumas são mais comuns no mercado, como padrões MVVM, Flux/Redux/Zustand, Design System, Feature Sliced Design...

Existem outras formas, mas não vou trazer todas - nem que eu quisesse, também não sei todas hahaha.

Mas é importante entender pontos fortes e fracos de cada uma, é um tradeoff emtre pesos.

Como gosto de construir os meus projetos​

Estrutura de pastas e Design de aplicações é um trema extremamente importante para o desenvolvimento de sites e aplicações. Vejo muitas pessoas não tendo ideia de como criar uma boa arquitetura de software, isso ocrore principalmente com quem atua com desenvolvimento Front-end.

Trago aqui uma arquitetura que trabalho há muitos anos e que de fato é eficiente e escala, é claro que é normal sofrer adaptações para alguns projetos e ela não é bala de prata, também sofre de necessidades e possui desvantagens, mas funcionou muito bem para a maioria dos projetos que trabalhei.

Projetos maiores com centenas de times pode necessitar de outro modelo, como monorepo, microfrontend e um design system destribuído. Mas não é o ocorre na maioria das empresas. Por tanto, a que trago abaixo é bem robusta:

src/  
├── pages/  
│   └── knowledge/  
│       ├── index.tsx  
│       ├── __tests__/  
│       │   └── knowledge.test.tsx  
│       ├── interfaces.ts  
│       ├── knowledge.tsx  
│       ├── action-bar.tsx  
│       ├── menu.tsx  
│       └── utils.ts  
├── routes/  
│   ├── auth.ts
│   ├── main.ts
│   ├── private.ts
│   ├── index.ts
├── componentes/  
│   ├── card/  
│   ├── button/  
│   ├── wallet/  
│   └── index.tsx  
├── providers/  
│   ├── main-provider.ts
├── templates/  
│   ├── main.tsx
│   ├── index.tsx
├── hooks/  
├── utils/  
├── types/  
│   ├── module.d.ts  
│   └── inference.d.ts  
├── commons/  
│   ├── i18n/  
│   ├── constants/  
│   ├── config/  
│   ├── react-query/  
│   └── styles/  
│       └── global.css  
├── assets/
│   ├── administration.svg  
│   └── spin.svg  
├── resources/  
│   ├── client/  
│   │   ├── knowledge.ts 
│   │   ├── cortex.ts
│   │   └── supabase.ts
│   └── api/  
│       ├── benchmarks/  
│       │   ├── contract.ts  
│       │   ├── index.ts  
│       │   └── services.ts

Referências:​