Diário do Projeto
Prompto

No ar no mesmo mês: por que não usei Laravel

Um desenvolvedor PHP de quinze anos escolhendo React Router e Cloudflare para um projeto próprio. Não foi curiosidade: foi a única forma de ir do zero ao ar em um mês sem infraestrutura para cuidar depois.

Performance Baseline

Do primeiro commit ao ar
1 mês

Escrevo PHP há mais de quinze anos e Laravel é onde sou mais produtivo. Foi o que escolhi para a Atendus, e por bons motivos.

Aqui escolhi outra coisa. Vale explicar por quê, porque a razão diz mais sobre o projeto do que sobre a tecnologia.

A restrição que definiu tudo

O Prompto é projeto próprio, sem cliente esperando e sem prazo comercial. Isso parece liberdade e é o contrário: projeto sem prazo é projeto que não termina.

Então me impus um: no ar dentro de dezembro. Um mês, contando do primeiro commit.

Com essa restrição, a pergunta deixou de ser “qual a melhor stack” e virou “qual stack me deixa entregar em um mês e não me dá trabalho depois?”. São critérios diferentes, e o segundo importa mais em projeto que eu vou manter sozinho nas horas vagas.

O que Laravel custaria aqui

Laravel resolveria o produto sem esforço. O custo não estava no código:

Servidor para manter. Aplicação PHP precisa de máquina, PHP-FPM, banco, certificado, backup, atualização de segurança. Para produto com cliente pagante isso se justifica. Para um projeto que talvez ninguém use, é uma conta mensal e uma responsabilidade permanente antes de saber se a ideia presta.

Front-end à parte de qualquer jeito. A interface do Prompto é interativa — preview em tempo real conforme você preenche variável, busca que filtra enquanto digita, editor com destaque. Isso pedia JavaScript de verdade. Com Laravel, eu teria PHP no servidor e um front separado: duas bases, dois deploys.

Latência. O público é global e o conteúdo é praticamente estático — prompt publicado muda pouco. Servir do edge é melhor que servir de uma máquina em uma região só.

O que escolhi

React Router v7 em modo full-stack, na Cloudflare. Uma base de código só, renderizando no servidor com streaming, rodando no edge.

O que isso me deu:

Uma linguagem, uma base, um deploy. Rota, carregamento de dado e interface no mesmo arquivo. Sem contrato de API entre front e back porque não há front e back separados.

Renderização no servidor de graça. A página chega pronta, o que importa para busca — biblioteca de prompts só tem valor se o Google indexar. Com aplicação puramente cliente, eu estaria construindo conteúdo que ninguém acha.

Zero servidor para cuidar. Sem máquina, sem patch de segurança, sem certificado vencendo no domingo. O custo em repouso é praticamente nada, o que para um projeto ainda não validado é o argumento decisivo.

Dados na mesma infraestrutura. Persistência, sessão e arquivo dentro da Cloudflare, sem banco gerenciado em outro provedor e sem latência atravessando nuvem.

A forma de uma rota — dado e interface juntos
import type { Route } from './+types/prompt';

// Roda no servidor, no edge, antes de renderizar
export async function loader({ params, context }: Route.LoaderArgs) {
  const prompt = await buscarPrompt(context, params.slug);
  if (!prompt) throw new Response('Não encontrado', { status: 404 });

  return { prompt, versoes: await buscarVersoes(context, prompt.id) };
}

// Roda no cliente, com o dado já resolvido
export default function Prompt({ loaderData }: Route.ComponentProps) {
  const { prompt, versoes } = loaderData;

  return (
    <article>
      <h1>{prompt.titulo}</h1>
      <PreviewComVariaveis texto={prompt.texto} variaveis={prompt.variaveis} />
      <HistoricoDeVersoes versoes={versoes} />
    </article>
  );
}

O loader executa no servidor e o componente recebe o resultado já pronto. Sem estado de carregamento, sem useEffect buscando dado, sem endpoint intermediário para manter.

O que doeu

Honestidade sobre o que a escolha cobrou:

Ergonomia. Eloquent, Artisan, migration e o ecossistema Laravel resolvem em minutos coisas que aqui levaram horas. A primeira semana foi mais lenta do que teria sido em terreno conhecido.

Menos bateria inclusa. Autenticação, autorização e validação vêm prontas no Laravel. Aqui foram decisões minhas, uma a uma. Para um produto pequeno, tudo bem; para algo do tamanho da Atendus, teria sido custo alto demais.

Limites do edge. Runtime de edge não é Node completo. Biblioteca que espera sistema de arquivos ou API específica de Node simplesmente não roda, e você descobre no deploy.

A conclusão que levo

A escolha certa depende da restrição dominante, e ela muda de projeto para projeto.

Na Atendus, a restrição é complexidade de domínio: muitos módulos, muitas regras, time crescendo. Laravel ganha porque maturidade de ecossistema vale mais que qualquer outra coisa.

No Prompto, a restrição era tempo até o ar e custo de manutenção. React Router na Cloudflare ganha porque elimina a operação inteira.

Escolher a stack pela linguagem que você domina é confortável. Escolher pela restrição que o projeto tem de verdade é o trabalho.

E o prazo foi cumprido: o Prompto entrou no ar em dezembro de 2025, no mesmo mês do primeiro commit.

React RouterCloudflareArquiteturaDecisão Técnica