O que o Laravel resolve antes de você escrever a primeira linha

Laravel é um framework PHP full stack com opinião. Ele entrega prontos os componentes que qualquer sistema corporativo precisaria construir ou colar de bibliotecas soltas: roteamento, camada de acesso a dados com Eloquent, migrations versionadas, validação, autenticação e autorização, filas, agendador de tarefas, envio de e-mail, cliente HTTP, cache e suíte de testes.

O ganho não é estético, é econômico. Cada peça dessas que a equipe não precisa projetar do zero é uma decisão a menos para revisar, documentar e manter. Em um sistema que vai viver cinco, oito anos em produção, o custo dominante não é o da primeira entrega, é o da manutenção: onboarding de novos desenvolvedores, padronização de código, atualização de dependências e correção de defeitos.

Convenções fortes também reduzem a variação entre times. Quando dois squads usam o mesmo framework com as mesmas convenções, um desenvolvedor transita entre projetos sem reaprender a estrutura de pastas, o padrão de migration ou a forma de disparar um job. Isso tem efeito direto em prazo.

Onde o framework não decide nada por você

Laravel resolve infraestrutura de aplicação. Ele não resolve modelagem de domínio, fronteiras entre módulos, consistência transacional com sistemas externos, multi-tenant, auditoria e retenção de dados. Essas continuam sendo decisões de arquitetura, e são elas que costumam determinar se o sistema envelhece bem.

Alguns pontos que aparecem com frequência em sistemas corporativos:

  • Eloquent em relatórios. O ORM é produtivo para CRUD e problemático para consultas analíticas. Relatórios gerenciais normalmente pedem SQL explícito com query builder ou views no banco, não navegação de relacionamentos.
  • Jobs e filas. Um job que fala com ERP, emissor de nota ou gateway de pagamento precisa ser idempotente. Retry sem chave de idempotência gera duplicidade, e duplicidade em processo financeiro custa caro.
  • Migrations em produção. Migration versionada é uma vantagem, desde que exista disciplina de execução em janela controlada e rollback testado. Migração que trava tabela grande derruba o sistema tanto quanto um bug.
  • Autorização. Policies e gates resolvem o controle por recurso, mas a regra de negócio (quem aprova o quê, em qual alçada) é do domínio e precisa ser testada como regra, não apenas como middleware.

Um caso concreto: portal de pedidos de uma distribuidora

Uma distribuidora de médio porte, com ERP legado e equipe pequena de TI, decidiu construir um portal B2B de pedidos em Laravel em vez de customizar o ERP. A escolha faz sentido: o framework entrega autenticação, filas e validação, e o time evolui o portal sem tocar no núcleo do ERP.

O problema apareceu na integração. O portal enfileirava cada pedido para envio ao ERP, e o job não tinha chave de idempotência. Quando o ERP demorava para responder, o job estourava o timeout e voltava para a fila. O pedido era enviado de novo. Resultado: pedidos duplicados no faturamento, conferência manual e atraso na expedição. A correção não foi trocar de framework, foi definir uma chave de negócio por pedido e tratar o job como operação idempotente.

Um segundo episódio, mais silencioso: o relatório de vendas por região, escrito com Eloquent e relacionamentos aninhados, passou a demorar minutos quando a base cresceu. A solução foi reescrever a consulta em SQL e criar um índice adequado. Nenhuma linha de infraestrutura mudou.

Na prática

Para quem mantém Laravel em produção, algumas rotinas separam operação tranquila de incidente:

  1. Fixe a versão do framework e planeje upgrades. Laravel evolui rápido; ficar duas versões atrás encarece a atualização e expõe o sistema a dependências sem correção.
  2. Trate filas como parte crítica da operação. Monitore com Horizon, defina tentativas, timeout e política de falha, e garanta idempotência em todo job que escreve em sistema externo.
  3. Revise queries antes de reclamar de performance. Lazy loading e N+1 aparecem cedo, e logs de query expõem o problema em desenvolvimento.
  4. Mantenha migrations pequenas e reversíveis, testadas em base com volume parecido com o de produção.
  5. Cubra com testes de feature os fluxos que atravessam banco, fila e serviço externo. São esses que quebram em produção.
  6. Restrinja ferramentas de debug ao ambiente local. Telescope e debugbar em produção expõem dados e degradam a resposta.

O framework entrega muito, mas o que sustenta o sistema em produção continua sendo disciplina de engenharia: contratos claros, testes e alguém responsável por revisar as decisões que o Laravel deixou em aberto.