Arquiteturas de Front-End: MPA, SPA, SSR, SSG
Quando usar MPA, SPA, SSR, SSG, ISR e micro-frontends. Trade-offs reais por caso de uso.
Definição
MPA: cada página é HTML do servidor. Ótimo SEO, sem JS inicial. SPA: HTML mínimo, toda navegação via JS. Transições rápidas, SEO ruim sem SSR. SSR: HTML renderizado a cada request — bom para SEO e dados frescos. SSG: HTML em build time — perfeito para conteúdo estático, CDN infinito. ISR: SSG com revalidação incremental. App Router do Next.js: Server Components por padrão + Client Components como islands.
Problema → Solução
Problema
Escolher SPA para e-commerce (ruim para SEO), SSR para dashboard interno (custo sem benefício), ou MPA quando precisam de transições ricas de UI.Solução
E-commerce público: SSR ou SSG+ISR (SEO + performance). Dashboard interno: SPA (sem SEO, estado complexo). Blog/marketing: SSG (conteúdo estático, CDN). App híbrido: Next.js com SSG para páginas públicas, SSR para dados personalizados, Client Components para interatividade.Dica de entrevista
Tip
Em 2025, Next.js App Router com Server Components é o padrão: SSR + islands de interatividade com zero configuração. A heurística: SSG onde possível, SSR onde necessário, Client Component só para interatividade.Código
// Next.js App Router: misturando arquiteturas por rota
// SSG com ISR (revalida a cada 60s)
const data = await fetch(url, { next: { revalidate: 60 } })
// SSR puro (a cada request)
const data = await fetch(url, { cache: 'no-store' })
// Server Component (padrão) — zero JS enviado ao cliente
async function ProductPage({ params }) {
const product = await db.product.findUnique(params.id)
return <ProductDetail product={product} />
}
// Client Component — apenas onde há interatividade
'use client'
function AddToCartButton({ productId }) {
const { addItem } = useCart()
return <button onClick={() => addItem(productId)}>Comprar</button>
}
// generateStaticParams: SSG com rotas dinâmicas
export async function generateStaticParams() {
const products = await getProducts()
return products.map(p => ({ id: p.id }))
}Perguntas de entrevista
Q.Quando usar SSR vs SSG?▾
A.SSG: conteúdo que não muda por usuário (blog, docs, landing page) ou muda raramente (catálogo com ISR). SSR: conteúdo personalizado por usuário (dashboard, feed) ou dados em tempo real (preço, estoque).
Q.O que são micro-frontends e quando fazem sentido?▾
A.Dividir o frontend em apps independentes com deploy separado por time. Faz sentido para: organizações grandes com times autônomos, partes com ciclos de release diferentes, ou migração gradual de legado. Custo alto — só justifica em escala real.
Q.CSR vs SSR: impacto em SEO?▾
A.CSR puro: Googlebot consegue indexar JS moderno mas outros bots não. Tempo de indexação maior. SSR/SSG: HTML com conteúdo chega direto, todos os bots indexam imediatamente. Para conteúdo público com necessidade de SEO, SSR/SSG é obrigatório.
Termos relacionados
58/122← →