Framework
Next.js 16 App Router
O app é construído com Next.js usando App Router. Renderização de páginas, route handlers, redirects e server actions vivem dentro da mesma estrutura de framework.
Stack principal
As peças centrais que fazem o fluxo de links curtos com marca própria funcionar.
UI
Tela administrativa em React 19
A interface principal é uma pequena UI administrativa em React para criar e apagar links curtos. Ela é propositalmente compacta e focada em uma única tarefa operacional, em vez de funcionar como um dashboard mais amplo.
Estilo
Tailwind CSS v4
O visual é feito com classes utilitárias do Tailwind e tokens compartilhados em app/globals.css. O resultado é uma interface escura, minimalista, com acentos em laranja e formulários leves.
Padrão de backend
Server actions + route handler
Mutações como login, logout, criação e exclusão vivem em app/actions.ts, enquanto o redirecionamento público é tratado por um arquivo de rota dedicado, sem depender de um serviço de API separado.
Armazenamento
Redis com fallback local em memória
Os registros de links passam pela abstração em lib/redis.ts. Em produção ela se conecta ao Redis via <code>ioredis</code>; no desenvolvimento local, pode cair para um Map em memória quando <code>REDIS_URL</code> não está definido.
Autenticação
Sessão por cookie + token administrativo
A autenticação é propositalmente simples: a senha é comparada com ADMIN_TOKEN e depois persistida em um cookie HTTP-only usando helpers em lib/auth.ts.
Como roda
O caminho de execução desde a tela administrativa até a resolução de um link curto.
1
A página administrativa valida autenticação primeiro
A página principal em app/page.tsx chama o helper de autenticação antes de renderizar. Usuários não autenticados são redirecionados para a tela de login.
2
Server actions cuidam do login e das mutações de links
Os fluxos dos formulários estão conectados às server actions em app/actions.ts . Essas actions validam entrada, checam autenticação, geram slugs quando necessário e disparam revalidação de cache para a página administrativa.
3
A criação de slugs usa validação mais geração base62
Slugs customizados são validados com helpers em lib/slug.ts . Se nenhum slug é enviado, o app testa alguns candidatos aleatórios em base62 até encontrar um ainda não usado.
4
Os links são gravados e listados pela camada de armazenamento
A camada de Redis salva cada registro, mantém um índice de slugs e devolve a lista ordenada por data de criação. A mesma interface também é usada pelo store em memória para trabalho local sem Redis.
5
Requisições públicas redirecionam por um route handler
Requisições para app/[slug]/route.ts fazem lookup do slug e emitem o redirect. Se o slug não existir, a rota devolve resposta 404.
Mapa da arquitetura
O repositório é pequeno, mas cada pasta tem um papel bem específico.
Pastas principais
app/Página administrativa, tela de login, server actions, componentes de formulário compartilhados e a rota pública de redirecionamento.
lib/Helpers de autenticação, validação e geração de slugs, além da abstração de armazenamento.
public/Assets estáticos como o ícone do app e SVGs auxiliares.
.vercel/Metadados locais da Vercel usados para deploy e tooling de desenvolvimento.
Análise da Arquitetura
app/page.tsx app/login/page.tsx app/[slug]/route.ts app/actions.ts lib/auth.ts lib/redis.ts lib/slug.ts
Este app é propositalmente mais estreito do que algo como Card Tracker. Ele não é um dashboard CRUD genérico nem um produto grande com múltiplas páginas. A arquitetura central é um pequeno fluxo administrativo autenticado combinado com um único endpoint público de redirect e uma abstração fina de armazenamento.
Dados e armazenamento
A persistência é simples e centrada em registros de slug.
Registro armazenado
Um link é apenas slug, URL e timestamp
Cada registro armazena o slug, a URL de destino e o momento de criação.
As chaves do Redis são separadas por slug e rastreadas por um índice ordenado.
A listagem usa esse índice, em vez de uma camada relacional de consultas.
Não há schema de banco, ORM ou sistema de migrações neste projeto.
Modo de fallback
O desenvolvimento local pode rodar sem Redis
Se REDIS_URL não estiver configurada, o app registra um aviso e usa um Map em memória.
Esse fallback simplifica bastante a configuração local, mas perde dados quando o processo reinicia.
A mesma interface de store é usada para Redis e memória, então o restante do app não precisa mudar.
Isso deixa o boot local especialmente leve.
Rotas e fluxo de requisição
A parte interessante do app é como ações administrativas e redirects públicos compartilham o mesmo código-base.
Superfície administrativa
app/page.tsx + app/login/
O lado administrativo usa páginas renderizadas no servidor com checagem de auth, formulários simples e server actions para todas as mudanças de estado. Não existe uma camada de API cliente separada para os fluxos centrais.
Superfície pública
app/[slug]/route.ts
O lado público é um route handler que recebe o slug, consulta a camada de armazenamento e redireciona para a URL de destino. Isso mantém o comportamento público extremamente pequeno e direto.
Comandos para rodar
O fluxo local é propositalmente mínimo.
Scripts
npm install npm run dev npm run build npm start
O projeto usa o ciclo padrão do Next.js: npm run dev para desenvolvimento local e npm run build para verificação de produção.
Ambiente esperado
O que o app precisa
ADMIN_TOKEN é obrigatória para acessar a interface administrativa.
REDIS_URL é usada para persistência em Redis na produção e pode ser omitida no modo local em memória.
Node.js, npm e o toolchain padrão do Next.js bastam para rodar o projeto.
Não há provedor externo de auth, ORM ou sistema de jobs em segundo plano.
Resumo final
Short URL é uma pequena utility full-stack em Next.js construída em torno de server actions, auth por cookie, armazenamento de links em Redis e uma rota direta de redirect. A força dele não está na complexidade, mas no foco: um fluxo administrativo com marca própria, um endpoint público por slug e uma configuração local de atrito muito baixo.