ToolAct

Demo

Página de demonstração

DadosSSR

Erro

Ocorreu um erro

O que é SSR?

Esta página demo não é uma ferramenta final para usuários, mas uma pequena rota de referência para renderização no servidor. Ela mostra como uma página do Next.js App Router pode buscar dados no servidor, renderizar o resultado no primeiro HTML e carregar os textos traduzidos do locale atual. Por isso é útil para verificar infraestrutura compartilhada: variáveis de ambiente, requisições assinadas no servidor, formato da resposta da API, roteamento por locale e carregamento de traduções. Se esta página funciona, o caminho básico de SSR está saudável antes de depurar uma ferramenta mais complexa. Se falha, o problema provavelmente está na configuração comum do servidor ou na conectividade com a API. Ela deve permanecer simples para funcionar como smoke test após deploys e mudanças de framework.

Como usar

Como usar

  1. A página chama automaticamente a API de back-end no servidor
  2. O HTML inclui conteúdo pré-renderizado, sem necessidade de requisição do cliente
  3. Visualize os dados retornados pela API
  4. Ideal para páginas que precisam de otimização de SEO

Notas de desenvolvimento

  • Use esta página como smoke test para SSR, carregamento de locale, requisições de servidor assinadas e conectividade de API.
  • Se esta página falhar, verifique a configuração compartilhada do servidor antes de depurar uma página de ferramenta específica.

Casos de uso

Verificar o caminho de API do servidor assinadoAbra a página demo para confirmar que os dados SSR podem ser buscados através do serverPageFetch com o locale atual e a configuração de API_BASE_URL. A página é force-dynamic, então os campos ret, msg, statusCode e data renderizados sempre refletem a resposta mais recente do servidor, o que é desejado para um smoke test. Este é um harness de depuração, não uma funcionalidade para usuários: uma resposta saudável nesta rota significa que a chave de assinatura compartilhada, o armazenamento de nonce e a negociação de locale estão todos em ordem antes de depurar uma ferramenta real.
Verificar como os campos de resposta do backend renderizam no shell do appA página exibe ret, msg, statusCode e data com um selo SSR, o que oferece aos desenvolvedores um smoke test compacto para formato de resposta e apresentação de estados de erro. Como a página é renderizada no servidor, é possível confirmar que o carregamento de mensagens i18n, o segmento de locale e o wrapper de signed-fetch funcionam sem instrumentar o cliente manualmente. Comparar o código ret e o título de erro renderizado lado a lado também ajuda a verificar se o mapeamento de erros está conectado corretamente, para que uma página real para o usuário mostre erros traduzidos em vez de strings brutas da API.
Usar como referência interna de integraçãoPor ser force-dynamic e renderizada no servidor, esta página é um exemplo compacto para futuras ferramentas que precisam de acesso assinado à API do servidor em vez de processamento puramente client-side. Use-a como referência funcional ao adicionar outra página SSR que chama o backend. Mantenha a superfície da demo mínima de propósito: um formato de resposta pequeno e previsível é o que torna o smoke test confiável, enquanto uma demo extensa obscureceria qual subsistema realmente falhou.
Capturar regressões de roteamento de locale com esta verificação SSRVisite a demo sob vários prefixos de locale para confirmar que os rótulos traduzidos e os campos ret/msg/data ainda renderizam no servidor, expondo problemas de roteamento ou do carregador de traduções antecipadamente. Uma chave de tradução ausente ou um segmento com erro em um locale geralmente aparece aqui antes que qualquer ferramenta para o usuário seja testada. Quando a demo falha em um locale mas passa em outro, a regressão quase sempre está no segmento de locale, no carregador de mensagens ou na árvore de roteamento, e não no wrapper de signed-fetch em si.
Verificar os headers X-Timestamp, X-Nonce e X-Sign no log de redeInspecione a requisição de saída da página demo para confirmar que o signed server fetch inclui os headers esperados, o que é a maneira mais rápida de depurar erros 401/403 da API real. Os mesmos headers também aparecem no DevTools do navegador ao fazer proxy pelo servidor de desenvolvimento local, então o wrapper de signed-fetch pode ser verificado ponta a ponta. Se a assinatura parece correta mas o upstream ainda rejeita, o desvio de relógio no servidor (X-Timestamp) ou uma colisão de nonce (X-Nonce) geralmente são os culpados, e o log de requisições da demo é o lugar mais limpo para confirmar ambos antes de abrir um ticket no backend.

Princípio técnico

Esta página Demo é construída sobre o Next.js 16 App Router e usa renderização no lado do servidor (SSR) por padrão. Quando um usuário solicita a página, o servidor Node.js primeiro executa o componente React, chama a API de back-end para obter os dados e então retorna o HTML totalmente renderizado ao navegador em uma única resposta. O navegador começa a analisar e renderizar o HTML imediatamente, então os usuários veem o conteúdo completo no primeiro quadro sem esperar que o JavaScript seja baixado e executado.

Isso contrasta fortemente com a renderização no lado do cliente (CSR) tradicional. No CSR, o servidor retorna apenas um shell HTML quase vazio e um link de JS; o navegador precisa baixar o pacote JS, executar a inicialização do framework, chamar APIs para buscar dados e só então renderizar a página. Do ponto de vista do usuário, isso é 'uma tela em branco por um tempo', e é ainda pior para rastreadores de mecanismos de busca — a maioria dos rastreadores não executa JavaScript e só vê o shell vazio.

Após o SSR, o Next.js também injeta um trecho de JavaScript para realizar a 'hidratação': associar o DOM existente à árvore de componentes React e vincular event listeners para que a página se torne interativa. O fluxo completo é: análise HTML → carregamento CSS → download JS → hidratação → página interativa. Entre os três Core Web Vitals, LCP (Largest Contentful Paint) e CLS (Cumulative Layout Shift) geralmente são melhores sob SSR, enquanto INP (Interaction to Next Paint) depende da velocidade de hidratação e da qualidade da implementação dos handlers de eventos.

  • Next.js App Router: páginas no App Router são Server Components por padrão, executando no servidor e retornando HTML automaticamente sem configuração extra.
  • SSR vs CSR: SSR entrega primeira pintura rápida e amigabilidade ao SEO ao custo de recursos do servidor; CSR se adequa a dashboards internos e outros cenários interativos que não precisam de SEO.
  • Fluxo da primeira pintura: análise HTML → carregamento e renderização CSS → download e execução de JS → hidratação React → página interativa; cada etapa afeta o LCP.
  • Amigabilidade ao rastreamento SEO: rastreadores mainstream como Googlebot e Bingbot leem o texto HTML diretamente; a saída SSR com conteúdo completo garante cobertura de rastreamento.
  • Limites dos Web Vitals: LCP < 2,5s, INP < 200ms, CLS < 0,1 são os limites 'bom' recomendados pelo Google; SSR facilita atingir LCP e CLS.
  • Requisições assinadas: a página Demo chama a API de back-end pelo serverApiFetch no servidor, carregando automaticamente X-Timestamp, X-Nonce e X-Sign para completar a autenticação.

Exemplos

SSR (Server-Side Rendering)

// app/page.tsx (Server Component padrão)
export default async function Page() {
  const data = await fetch('/api/info').then(r => r.json());
  return <div>{data.title}</div>;
}
// O HTML já contém diretamente <div>conteúdo real</div>

CSR (Client-Side Rendering)

'use client';
import { useEffect, useState } from 'react';

export default function Page() {
  const [data, setData] = useState(null);
  useEffect(() => {
    fetch('/api/info').then(r => r.json()).then(setData);
  }, []);
  return <div>{data?.title || 'Loading...'}</div>;
}
// O HTML do primeiro paint contém apenas <div>Loading...</div>

Comparação de velocidade do primeiro paint

# SSR
FCP: 0.4s  LCP: 0.8s  TTI: 1.2s
SEO: crawlers recebem o conteúdo completo diretamente

# CSR
FCP: 0.6s  LCP: 1.8s  TTI: 2.4s
SEO: crawlers precisam executar JS para obter o conteúdo

Perguntas frequentes

O que esta página de demonstração realmente está demonstrando?

É uma rota de referência de renderização no servidor (SSR) que mostra como uma página do Next.js App Router pode buscar dados no servidor, embutir o resultado na primeira resposta HTML e ainda assim carregar os textos localizados corretos. Não é uma utilidade para usuário final — é um teste de fumaça para desenvolvedores.

Os dados são buscados no servidor ou no navegador?

No servidor. A página chama serverApiFetch (com os cabeçalhos de requisição assinada de src/lib/sign.ts) dentro do React Server Component, então o navegador recebe uma página HTML que já contém os dados. Não há fetch no cliente no primeiro carregamento.

Por que a página às vezes mostra dados desatualizados?

O Next.js pode armazenar a resposta SSR em cache dependendo das configurações de revalidate. Se você precisa de dados atualizados a cada requisição, defina 'export const dynamic = "force-dynamic"' ou passe {cache: 'no-store'} para o fetch. A rota de demonstração usa o comportamento padrão para manter o exemplo simples.

Posso copiar esse padrão para minha própria página?

Sim — essa é a ideia. A rota mostra como combinar getTranslations do next-intl com um fetch no servidor e passar o resultado para um Client Component para interatividade. Copie o layout.tsx e o page.tsx e substitua a fonte de dados.

Por que preciso assinar as requisições para uma API interna?

X-Timestamp / X-Nonce / X-Sign bloqueiam ataques de replay e garantem que requisições vindas da web pública realmente partem de um cliente confiável. A chave de assinatura é por sessão para usuários logados e um valor padrão caso contrário; veja src/lib/sign.ts e src/lib/fetch.ts para a implementação.

Esta página existe em builds de produção?

Faz parte do app implantado para referência, mas não é linkada na home nem na lista de ferramentas, e não é divulgada como uma ferramenta para o usuário. Trate como documentação de desenvolvedor renderizada como rota.

O que devo olhar para entender a estrutura do projeto?

Comece pelo layout.tsx e page.tsx desta página, depois leia src/i18n.ts (configuração de locale), src/i18n/request.ts (carregamento global de traduções), src/lib/load-page-messages.ts (traduções por página) e src/lib/fetch.ts (wrappers de requisição assinada).

Ferramentas relacionadas

Gerador UUID

Gerador UUID online gratuito criando identificadores únicos compatíveis com RFC 4122. Suporte a versões UUID v1, v4, geração em lote.

Contador de Tokens

Ferramenta online gratuita para contar tokens e estimar a quantidade em modelos de IA como GPT e Claude.

Consulta de Códigos de Status HTTP

Referência de códigos de status HTTP online gratuita com todos os códigos padrão. Pesquise e filtre por categoria

Referência de Tipos MIME

Ferramenta de consulta de tipos MIME online gratuita. Encontre rapidamente tipos MIME para extensões de arquivos.

Referência de Comandos Git

Guia de referência rápida dos comandos Git online e gratuito com os comandos mais usados, organizados por categoria com pesquisa e filtro.

Consulta de Tabela ASCII

Referência de tabela ASCII online gratuita com caracteres de controle, caracteres imprimíveis e caracteres estendidos.