Neste artigo, vou mostrar como funciona, na prática, um sistema real de cobrança construído em Laravel, integrando Boleto e Pix do Banco Inter, com webhooks, PDFs, crons, Docker, e-mails, WhatsApp, SMS e até ligações automáticas.

Todo o conteúdo é baseado em um projeto open source real, usado em produção, disponível no GitHub:

👉 Repositório:
https://github.com/leonardop21/boleto-inter-free

Importante: este não é um “tutorial de Hello World”. É um guia técnico completo, voltado para quem quer entender arquitetura, evitar erros comuns e colocar cobrança automática em produção com segurança.

Por que integrar diretamente com o Banco Inter?

O Banco Inter oferece uma API robusta para PJ, com suporte nativo a:

• Boletos registrados
• Pix com QR Code dinâmico
• Webhooks de status
• Consulta de cobranças
• Download de PDFs
• Extratos bancários

Ao integrar diretamente com o Inter, você elimina intermediários, reduz custos e ganha controle total sobre o fluxo financeiro.

Mas isso vem com desafios:

• Certificados mTLS
• OAuth2
• Regras rígidas de vencimento
• Webhooks que precisam ser idempotentes
• PDFs que precisam ser armazenados ou regenerados
• Conciliação automática

É exatamente isso que o projeto resolve.

Visão geral da arquitetura do sistema

Antes de entrar em código, é importante entender como o sistema foi pensado.

Componentes principais

• Laravel 8 como base
• MySQL para dados transacionais
• Redis para cache com tags
• Banco Inter API para cobranças
• Notifish para WhatsApp
• SMTP para e-mails
• SMS Dev para SMS
• King SMS (Voicer) para ligações
• Docker + Nginx + PHP-FPM em produção

Nada aqui é experimental. Tudo foi pensado para rodar 24/7, com falhas previsíveis e logs rastreáveis.

Por que Redis é obrigatório neste projeto?

Um erro comum em sistemas de cobrança é consultar a API do banco o tempo todo.

Esse projeto evita isso usando cache agressivo com tags, por exemplo:

• Cache de cobranças
• Cache de clientes
• Cache de serviços
• Cache de status de boletos e Pix

Quando um boleto muda de status (via webhook), o cache relacionado é invalidado.

👉 Sem Redis (ou Memcached), o sistema não funciona corretamente.

Instalação do projeto (ambiente local)

1. Clonando o repositório

git clone https://github.com/leonardop21/boleto-inter-free.git
cd boleto-inter-free
composer install

2. Configuração inicial

cp .env.example .env
php artisan key:generate

Configurando o banco de dados e cache

No .env:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=boleto_inter
DB_USERNAME=user
DB_PASSWORD=pass

CACHE_DRIVER=redis
SESSION_DRIVER=redis
TIME_CACHE_IN_SECONDS=604800

Depois:

php artisan migrate

Como funciona o modelo de cobrança

O sistema foi pensado para cobrança recorrente, mas funciona também para cobranças pontuais.

Entidades principais

• Cliente
• Serviço
• Cliente x Serviço
• Boleto
• Pix
• NF-e (opcional)

O fluxo é simples:

1. Você cadastra um cliente
2. Cadastra um serviço
3. Vincula o serviço ao cliente
4. O sistema gera boletos ou Pix automaticamente

Integração com o Banco Inter (parte crítica)

Certificados mTLS

O Inter exige:

• Um arquivo .crt
• Um arquivo .key

No .env:

INTER_PATH_CRT=/caminho/inter.crt
INTER_PATH_KEY=/caminho/inter.key

OAuth2

INTER_CLIENT_ID=seu_client_id
INTER_CLIENT_SECRET=seu_client_secret
INTER_CLIENT_SCOPE="extrato.read boleto-cobranca.read boleto-cobranca.write"
INTER_BASE_URL="https://cdpj.partners.bancointer.com.br/"

Sem isso, nenhuma requisição funciona.

Webhooks: o coração da automação

O sistema registra dois webhooks no Inter:

• Boleto
• Pix

INTER_WEBHOOK_URL=https://seusite.com/api/inter/webhook/boleto
INTER_WEBHOOK_URL_PIX=https://seusite.com/api/inter/webhook/pix

O que acontece quando um pagamento é feito?

1. O Inter chama o webhook
2. O sistema valida a assinatura
3. Atualiza o status da cobrança
4. Invalida caches relacionados
5. Registra logs
6. (Opcional) dispara notificações internas

Isso evita:

• Jobs de polling
• Consultas desnecessárias
• Status desatualizado

Geração automática de boletos

Este é um dos pontos mais sofisticados do projeto.

Comando:

php artisan ln:auto_generate_boleto

Regras implementadas

• Se o dia de vencimento já passou → gera para o mês seguinte
• Se o cliente escolheu dia 31 → ajusta para último dia do mês
• Respeita meses com 28, 29, 30 ou 31 dias
• Evita boletos duplicados
• Gera PDF automaticamente
• Salva logs detalhados

Tudo isso roda sem intervenção humana.

Geração automática de Pix

Comando:

php artisan ln:auto_generate_pix

• Gera QR Code
• Gera payload Pix
• Cria cobrança no Inter
• Registra vencimento
• Gera imagem do QR Code (GD)

Envio de cobranças por e-mail

O sistema envia:

• Boleto em PDF
• Pix com QR Code
• NF-e (se configurado)

Configuração SMTP no .env:

MAIL_HOST=
MAIL_PORT=587
MAIL_USERNAME=
MAIL_PASSWORD=
MAIL_ENCRYPTION=tls

Além disso, o layout do e-mail é personalizável:

• Logo
• Cor de fundo
• Links de suporte

Envio por WhatsApp (Notifish)

Integração direta com a API do Notifish.

NOTIFISH_BASE_URL=https://seu.notifish.com/api/v2/
NOTIFISH_API_KEY=sua_key
NOTIFISH_UUID=sua_instancia

O sistema gera uma URL assinada temporária para o PDF do boleto, válida por poucos minutos — sem expor IDs internos.

SMS e ligações automáticas para inadimplentes

SMS

php artisan ln:send-boleto-sms
php artisan ln:send-pix-sms

Ligação (voz robótica)

php artisan ln:send-boleto-voicer
php artisan ln:send-pix-voicer

Isso é usado somente após o vencimento, como camada extra de cobrança.

Crons: como tudo roda sozinho

Você não agenda cada comando individualmente.

Apenas:

* * * * * php artisan schedule:run

O Laravel Scheduler cuida do resto.

Exemplo:

• Dia 1 → gera boletos
• Antes do vencimento → envia lembrete
• Após vencimento → cobrança progressiva

Docker em produção

O projeto já vem com:

• Dockerfile
• docker-compose.prod.yml
• Nginx configurado
• PHP-FPM otimizado
• Redis
• MySQL

Subir produção:

docker compose -f docker-compose.prod.yml up -d --build

Logs, rastreabilidade e auditoria

Cada processo tem seu próprio log:

• Boletos
• Pix
• NF-e
• Webhooks
• Erros de API

Isso é fundamental para:

• Suporte
• Auditoria
• Contabilidade
• Diagnóstico rápido

Para quem este projeto é indicado?

• Desenvolvedores PHP/Laravel
• SaaS com cobrança recorrente
• Sistemas internos de empresas
• Agências que querem padronizar cobrança
• Projetos que precisam de autonomia financeira

Conclusão

Automatizar cobranças não é só “gerar boleto”.
É lidar com:

• Datas
• Erros bancários
• Comunicação
• Inadimplência
• Escala
• Observabilidade

Este projeto resolve isso de forma pragmática, realista e testada em produção.

👉 Repositório completo:
https://github.com/leonardop21/boleto-inter-free

The post Sistema completo de cobranças via WhatsApp: boleto, Pix e NF-e na prática appeared first on Leonardo Nascimento | Engenheiro de Software.

A forma correta de fazer isso é tratar WhatsApp como camada de notificação, não como sistema de monitoramento. Você continua monitorando com ferramentas e sinais confiáveis (uptime, métricas, logs, filas, erros), mas centraliza o envio e a governança dos alertas em um lugar só — e aí o Notifish entra bem.

A ideia é simples: qualquer evento relevante → vira um “evento de notificação” → Notifish entrega no WhatsApp.

O que vale a pena mandar para o WhatsApp (e o que não vale)

WhatsApp deve receber só o que exige ação ou atenção rápida. Em produção, eu separo em três níveis:

Crítico (manda sempre):

• aplicação fora do ar / endpoint crítico fora
• erro 5xx em alta (explosão de taxa de erro)
• fila parou de consumir / backlog crescendo rápido
• disco quase cheio / risco de indisponibilidade
• falha em integração crítica (pagamento, mensagens, etc.)

Alerta (manda com filtro):

• latência acima do normal por X minutos
• aumento gradual de erros específicos
• Redis indisponível (com fallback) ou lento
• uso de CPU/memória alto por período sustentado

Informativo (geralmente não manda no WhatsApp):

• deploy realizado
• logs de rotina
• warnings esporádicos

O que destrói o canal é “alerta informativo demais”. WhatsApp é para sinal forte.

Arquitetura recomendada (sem gambiarra)

O melhor padrão é este:

1. Você tem fontes de evento (monitoramento/observabilidade):

• Uptime/health-check (aplicação)
• Métricas do servidor (CPU, RAM, disco)
• Logs (erros específicos, padrões)
• Erros de aplicação (exceptions)
• Filas (backlog, falhas, retries)

2. Um “gerador de eventos” cria um evento padronizado.
3. Você envia esse evento para o Notifish via API.
4. Você define roteamento, deduplicação e templates

• para qual número/grupo enviar
• se deve agrupar, deduplicar, aplicar rate limit
• qual template usar (curto, completo, escalonamento)

Esse desenho escala porque você não espalha envio de WhatsApp por todo sistema. Você centraliza.

Como fica uma mensagem boa no WhatsApp

Uma mensagem útil precisa ter contexto mínimo e ação sugerida:

• Título curto (o que aconteceu)
• Ambiente (prod, staging)
• Serviço (api, worker, site)
• Sintoma (erro, timeout, backlog)
• Impacto (estimado)
• Link (dashboard/logs, se existir)
• Ação recomendada (1 linha)

Exemplo de payload humano:

ALERTA CRÍTICO: API 5xx alto
Ambiente: prod | Serviço: api
Erros 5xx: 18% (últimos 5 min)
Endpoint: /api/orders
Ação: verificar logs + dependência “Payments”

Implementação via API com Notifish (modelo prático)

Você pode integrar de dois jeitos:

1) Seu sistema envia eventos diretamente (Laravel, cron, scripts)

Bom quando você mesmo detecta (fila, logs, métricas internas).

2) Ferramentas externas chamam o Notifish (uptime/monitoramento)

Bom para health-check e métricas do servidor (quando a ferramenta já faz o “detector”).

Como você pediu implementação via API, vou te mostrar um modelo que funciona bem

Payload recomendado (evento)

{
  "message": "Sua mensagem de alerta",
  "identifier": "seu identificador único de disparo",
  "link": true,
  "typing": "composing",
  "delayMessage": 1200
}

Por que esse formato funciona:

• identifier: chave de deduplicação / idempotência do alerta
• message: texto já formatado com contexto (ambiente/serviço/ação)
• delayMessage/typing: ajustes de entrega (opcionais)

Exemplo em Laravel enviando evento ao Notifish

class NotifishClient
{
    public function sendToGroups(string $message, string $identifier, bool $link = true, int $delayMs = 0, string $typing = 'composing'): void
    {
        $url = rtrim(config('services.notifish.base_url'), '/')
            . '/api/v2/' . config('services.notifish.instance')
            . '/whatsapp/message/groups';

        $payload = [
            'message' => $message,
            'identifier' => $identifier,
            'link' => $link,
            'typing' => $typing,
            'delayMessage' => $delayMs,
        ];

        $response = Http::withToken(config('services.notifish.token'))
            ->acceptJson()
            ->contentType('application/json')
            ->timeout(8)
            ->post($url, $payload);

        if (!$response->successful()) {
            logger()->error('Notifish send failed', [
                'status' => $response->status(),
                'body' => $response->body(),
                'identifier' => $identifier,
            ]);
        }
    }
}

Regras importantes para não virar caos

Se você fizer só “manda mensagem”, em 2 semanas o canal morre. Algumas regras que eu considero obrigatórias:

1) Deduplicação

• Todo alerta precisa de dedupe_key.
• Se o mesmo alerta acontecer 100 vezes, você manda 1 e “atualiza”/agrupa.

2) Rate limit por severidade

• Crítico: pode repetir, mas com intervalo mínimo (ex.: 5–10 min).
• Alerta: intervalo maior (ex.: 15–30 min).
• Informativo: geralmente fora do WhatsApp.

3) Idempotência

• Eventos iguais devem produzir o mesmo estado.
• Se a chamada repetir, não deve disparar em duplicidade.

4) Conteúdo curto
WhatsApp é leitura rápida. Se precisar detalhe, coloque em meta e mande link para logs/dashboard quando possível.

5) Escalonamento
Se continuar crítico por X tempo, notifica outro grupo/gestor.

O que monitorar para disparar eventos úteis (fontes típicas)

Você pode começar com estes gatilhos (são os que mais dão retorno):

• Health-check HTTP (200/500, tempo de resposta, quedas)
• Taxa de erro (5xx e exceções por minuto)
• Fila (backlog, jobs failed, tempo médio)
• Banco (conexões, queries lentas, timeouts)
• Redis (latência, indisponibilidade, memória/eviction)
• Servidor (disco, load alto sustentado)
• Integrações externas (timeout e falha por janela)

Monitorar “pelo WhatsApp” não é substituir observabilidade por chat. É transformar sinais importantes em alertas acionáveis, com governança. O Notifish entra como a peça que centraliza o envio e impede que cada sistema invente seu próprio jeito de notificar.

Se você faz dedupe, rate limit, severidade e contexto mínimo, o WhatsApp vira um canal confiável — e não um spam de produção.

The post Como monitorar aplicação e servidor pelo WhatsApp (logs, erros e alertas) appeared first on Leonardo Nascimento | Engenheiro de Software.

Este artigo detalha a arquitetura de uma API REST desenvolvida em Laravel para gerenciamento de tarefas, criada como parte de um teste técnico, mas estruturada como um projeto pronto para produção, seguindo boas práticas amplamente utilizadas em ambientes corporativos.

Visão geral da solução

A aplicação consiste em uma API RESTful para gerenciamento de tarefas, com suporte a:

• Autenticação via Bearer Token (Laravel Sanctum)
• CRUD completo de tarefas
• Marcação de tarefas como concluídas
• Cache de consultas com Redis
• Banco de dados PostgreSQL
• Documentação interativa via Swagger
• Ambiente Dockerizado (dev, test e prod)
• Testes automatizados
• Pipeline de CI/CD com GitHub Actions

O foco não foi apenas “fazer funcionar”, mas pensar a aplicação como um produto escalável e previsível.

Decisão arquitetural: API stateless e autenticação

A API foi construída como stateless, utilizando Bearer Token via Laravel Sanctum.

Benefícios dessa abordagem:

• Facilidade de integração com frontends (SPA, mobile, terceiros)
• Independência de sessão
• Escalabilidade horizontal
• Compatibilidade com gateways, load balancers e proxies

A autenticação é desacoplada do fluxo de negócio, o que facilita manutenção e evolução futura.

PostgreSQL como banco principal

A escolha do PostgreSQL não foi aleatória. Ele é amplamente utilizado em ambientes corporativos por oferecer:

• Confiabilidade transacional
• Suporte avançado a índices
• Tipos de dados ricos
• Excelente desempenho em cenários complexos

Isso torna a aplicação preparada para crescer sem precisar trocar a base de dados no curto ou médio prazo.

Redis como camada de cache

Para reduzir carga no banco e melhorar tempo de resposta, foi implementado cache com Redis, com TTL de 120 segundos nas consultas mais comuns.

Benefícios diretos:

• Redução de queries repetitivas
• Menor latência
• Melhor desempenho sob carga
• Escalabilidade em leitura

Essa abordagem demonstra preocupação com performance real, não apenas com lógica funcional.

Arquitetura limpa: Repository Pattern + Service Layer

A aplicação segue princípios de Clean Architecture, separando responsabilidades de forma clara:

• Controllers: recebem requisições e retornam respostas
• Services: concentram regras de negócio
• Repositories: isolam o acesso a dados
• Models: representam as entidades

Vantagens dessa separação:

• Código mais legível
• Facilidade de testes
• Menor acoplamento
• Evolução segura do domínio

Essa estrutura é comum em times maduros e projetos de longo prazo.

Docker como base do ambiente

Toda a aplicação roda em Docker, com ambientes bem definidos:

Desenvolvimento

• Código em volume
• Hot reload
• PostgreSQL + Redis + Nginx
• Testes executados automaticamente

Produção

• Build otimizado
• Código embutido na imagem
• Assets compilados no build
• Sem dependência de volume

Essa separação reduz o clássico problema de “funciona na minha máquina” e aproxima o ambiente local da produção.

Testes automatizados como parte do fluxo

A aplicação conta com testes unitários e de feature, executados de três formas:

• Localmente no ambiente dev
• Isoladamente via Docker
• Automaticamente no CI/CD

Isso garante:

• Segurança para refatorações
• Detecção precoce de bugs
• Confiança na entrega contínua

Testes não são tratados como opcional, mas como parte da arquitetura.

CI/CD com GitHub Actions

Cada push ou pull request dispara um workflow que:

1. Sobe toda a stack Docker (app, banco, cache)
2. Executa migrations
3. Roda a suíte completa de testes
4. Bloqueia o merge em caso de falha

Esse processo simula um pipeline real de empresas que operam com entrega contínua e qualidade de código como requisito.

Documentação com Swagger

A API possui documentação interativa via Swagger, acessível após subir a aplicação.

Isso permite:

• Testes manuais rápidos
• Onboarding mais fácil
• Comunicação clara entre backend e frontend
• Uso por terceiros sem dependência de documentação externa

Documentação é tratada como parte do produto, não como etapa posterior.

Benefícios dessa arquitetura em um contexto profissional

Essa abordagem entrega vantagens claras em ambientes reais:

• Código organizado e previsível
• Facilidade de manutenção
• Escalabilidade técnica
• Padronização de ambientes
• Menor risco em deploys
• Base sólida para crescimento

Não se trata apenas de uma API de tarefas, mas de um modelo replicável para aplicações reais.

O que esse projeto demonstra tecnicamente

Esse projeto evidencia competências como:

• Domínio de Laravel além do básico
• Conhecimento de arquitetura backend
• Uso consciente de cache e banco
• Experiência com Docker e ambientes reais
• Cultura de testes
• Automação de CI/CD
• Pensamento orientado a produto e escala

São exatamente esses pontos que diferenciam um desenvolvedor pleno/sênior em processos seletivos.

Conclusão

Mais do que cumprir um teste técnico, o objetivo deste projeto foi demonstrar capacidade de pensar sistemas como um todo, indo além do CRUD simples.

Arquitetura, automação, testes e previsibilidade são o que tornam uma aplicação sustentável — e é isso que empresas buscam quando contratam profissionais para projetos de longo prazo.

Link do teste prático

The post Arquitetura de uma API REST em Laravel preparada para produção appeared first on Leonardo Nascimento | Engenheiro de Software.

Com a aprovação no diretório oficial, o plugin passa a atender padrões rígidos de segurança, qualidade de código e boas práticas exigidas pela equipe do WordPress, o que garante mais confiabilidade para quem busca soluções profissionais de distribuição de conteúdo.

👉 Repositório oficial do plugin:
https://wordpress.org/plugins/notifish/

O que é o plugin Notifish

O Notifish é um plugin que conecta o WordPress à plataforma Notifish, permitindo que publicações sejam enviadas automaticamente para grupos, listas ou contatos no WhatsApp a partir do momento em que um post é publicado ou atualizado.

Na prática, ele elimina processos manuais comuns em portais, blogs e sites de conteúdo, como copiar links, formatar mensagens e disparar envios individualmente, centralizando tudo dentro do próprio fluxo editorial.

Para quem o Notifish é indicado

O plugin foi desenvolvido para cenários reais de uso, como:

• Portais de notícias e sites jornalísticos
• Blogs com publicação frequente
• Produtores de conteúdo e infoprodutores
• Empresas que usam WhatsApp como canal de comunicação
• Projetos WordPress que dependem de distribuição rápida de conteúdo

Em todos esses casos, o WhatsApp deixa de ser apenas um canal complementar e passa a fazer parte da estratégia de publicação.

Como funciona a integração com o WordPress

Após a instalação do plugin e a configuração da chave de API, o funcionamento é simples:

1. O conteúdo é publicado normalmente no WordPress
2. O plugin identifica a publicação
3. O Notifish envia a mensagem para os grupos ou listas configuradas
4. O envio fica registrado para controle e auditoria

Todo o processo acontece de forma transparente para o editor, sem necessidade de ferramentas externas ou fluxos paralelos.

Principais vantagens do Notifish

Automação real no fluxo editorial

O envio das mensagens acontece no momento certo, integrado ao ciclo de publicação, sem depender de ações manuais.

Distribuição imediata do conteúdo

Assim que a matéria vai ao ar, ela já pode ser entregue ao público em um canal com alta taxa de abertura e leitura.

Centralização de operações

O WordPress deixa de ser apenas um CMS e passa a ser também um ponto central de distribuição de conteúdo.

Mais controle sobre comunicação via WhatsApp

O uso de automação reduz falhas humanas, duplicidade de envios e inconsistências na comunicação.

Aprovação no repositório oficial do WordPress

A presença do Notifish no repositório oficial do WordPress é um ponto relevante, pois indica que o plugin:

• Segue as diretrizes de segurança do WordPress
• Utiliza boas práticas de desenvolvimento
• Passou por revisão manual da equipe do WordPress
• Pode ser instalado e atualizado diretamente pelo painel administrativo

Isso reduz riscos técnicos e aumenta a confiabilidade do projeto para uso em produção.

Impacto em SEO e engajamento

Embora o WhatsApp não seja um fator direto de ranqueamento, a automação de distribuição impacta positivamente métricas importantes para SEO, como:

• Aumento de tráfego recorrente
• Maior taxa de retorno ao site
• Crescimento de engajamento com o conteúdo
• Ampliação do alcance orgânico das publicações

Em projetos editoriais, isso significa conteúdo sendo consumido mais rápido e com mais frequência.

Onde instalar o plugin Notifish

O plugin está disponível no repositório oficial do WordPress e pode ser instalado diretamente pelo painel administrativo ou acessado pelo link abaixo:

https://wordpress.org/plugins/notifish

Considerações finais

O Notifish não é apenas um plugin de envio de mensagens, mas uma ferramenta de integração entre conteúdo e distribuição, pensada para quem publica com frequência e precisa de escala sem perder controle.

Para sites WordPress que utilizam o WhatsApp como canal estratégico, a automação deixa de ser um diferencial e passa a ser uma necessidade operacional.

The post Automação de WhatsApp para WordPress: uma solução escalável para empresas e portais appeared first on Leonardo Nascimento | Engenheiro de Software.

O que diferencia um dev mais experiente não é o que ele sabe fazer, mas o que ele evita fazer.

Vou te ensinar aqui um padrão prático, usado em projetos reais, que resolve três problemas clássicos:

• Controllers inchados
• Regras de negócio espalhadas
• Código impossível de testar ou evoluir

public function store(Request $request)
{
if (!$request->email) {
return response()->json([‘error’ => ‘Email obrigatório’], 422);
}

$user = User::create([
    'name' => $request->name,
    'email' => $request->email,
]);

Mail::to($user->email)->send(new WelcomeMail($user));

Log::info('Usuário criado', ['id' => $user->id]);

return response()->json($user);

}

Funciona? Funciona.

É bom? Não.

Por quê?

• Controller decide regra de negócio
• Controller cria usuário
• Controller dispara e-mail
• Controller registra log

Isso acopla tudo.

Pensamento pleno/sênior: separar responsabilidade

Controller não decide regra.
Controller orquestra.

Vamos refatorar com um Service + DTO, padrão simples e poderoso.

Criando um DTO (Data Transfer Object)

Isso evita Request sendo usado como regra de negócio.

final class CreateUserDTO
{
    public function __construct(
        public readonly string $name,
        public readonly string $email,
    ) {}
}

Simples, explícito e tipado.

Criando o Service (onde a regra mora)

final class CreateUserService
{
    public function execute(CreateUserDTO $dto): User
    {
        if (!filter_var($dto->email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException('Email inválido');
        }

        $user = User::create([
            'name' => $dto->name,
            'email' => $dto->email,
        ]);

        Mail::to($user->email)->send(new WelcomeMail($user));

        Log::info('Usuário criado', ['id' => $user->id]);

        return $user;
    }
}

Agora sim:

• Regra centralizada
• Código reutilizável
• Fácil de testar
• Fácil de evoluir

Controller limpo (como deveria ser)

public function store(Request $request, CreateUserService $service)
{
    $dto = new CreateUserDTO(
        name: $request->name,
        email: $request->email
    );

    $user = $service->execute($dto);

    return response()->json($user);
}

O controller:

• Recebe request
• Constrói DTO
• Chama serviço
• Retorna resposta

Nada além disso.

O ganho real (que júnior não enxerga)

Testabilidade

Agora você testa a regra sem framework:

public function test_user_creation()
{
    $service = new CreateUserService();

    $dto = new CreateUserDTO(
        name: 'Leo',
        email: 'leo@email.com'
    );

    $user = $service->execute($dto);

    $this->assertEquals('Leo', $user->name);
}

Sem Request.
Sem Controller.
Sem gambiarra.

Evolução sem dor

Amanhã você precisa:

• Enviar evento para fila
• Criar usuário em sistema externo
• Validar regra nova

Você altera um lugar só.

Mentalidade sênior (isso vale ouro)

” Código que funciona não é código bom.mCódigo bom é o que aguenta mudança.”

Pleno/sênior pensa assim:

• Onde essa regra deve morar?
• O que vai mudar daqui 6 meses?
• Quem vai dar manutenção nisso?

Erros clássicos que isso evita

• Fat models
• Controllers gigantes
• Services que viram controllers
• Regra duplicada
• Código impossível de refatorar

Esse tipo de abordagem não aparece em tutorial de YouTube, mas é exatamente o que mantém sistemas vivos em produção.

The post PHP além do CRUD: como escrever código que não vira problema em produção appeared first on Leonardo Nascimento | Engenheiro de Software.

Spoiler: quando é ruim, os sinais aparecem rápido

Projetos WordPress mal feitos não falham em silêncio. Eles deixam rastros.
O problema é que muita gente não sabe onde olhar.

Em 10 minutos, você consegue ter uma boa noção se está diante de:

• Um projeto profissional ou uma bomba-relógio disfarçada de site bonito

Abra o site no celular (primeiro minuto)

Antes de qualquer ferramenta, abra no mobile.

Sinais clássicos de problema:

• Site lento para carregar
• Layout “pulando”
• Texto pequeno ou mal espaçado
• Elementos quebrados

Se o site já sofre no mobile, o problema geralmente é estrutural — não é “só ajuste fino”.

Inspecione o HTML (2 minutos)

Clique com o botão direito → Inspecionar.

Se você vê:

• Camadas infinitas de <div>
• Classes genéricas e repetidas
• Estrutura semântica inexistente
• Conteúdo principal perdido no meio do código

Isso indica HTML inflado, típico de projetos feitos no arrastar e soltar.

HTML ruim é sinal de:

• SEO fraco
• Performance ruim
• Manutenção difícil

Veja quantos arquivos CSS e JS são carregados (1 minuto)

Abra a aba Network do navegador.

Red flags claras:

• 15, 20, 30 arquivos CSS
• JS sendo carregado em todas as páginas, sem necessidade
• Scripts de plugins que nem aparecem na tela

Quanto mais dependência global, pior a saúde do projeto.

Cheque a hierarquia de títulos (H1, H2, H3) (1 minuto)

Use qualquer extensão simples ou até o próprio inspector.

Problemas comuns:

• Mais de um H1
• H1 usado como elemento visual
• Pulando de H2 para H4
• Headings usados só para “aumentar fonte”

Isso é um tiro no pé para SEO e acessibilidade.

Abra o painel administrativo (2 minutos)

Se você tem acesso ao admin, a verdade aparece rápido.

Sinais de alerta:

• 15, 30, 50 plugins ativos
• Plugins com funções sobrepostas
• Plugins abandonados ou sem atualização
• Tudo resolvido com plugin, nada com código

Projeto bom usa plugin como ferramenta, não como muleta.

Dê uma olhada no banco de dados (1 minuto)

Mesmo sem aprofundar, alguns sinais gritam:

• Tabelas demais para um site simples
• Prefixos estranhos
• Plugins que criaram dezenas de tabelas
• Lixo acumulado de plugins removidos

Quando um site institucional tem mais de 200 tabelas, algo está muito errado. (História real)

Veja como o cache está sendo tratado (1 minuto)

Perguntas simples:

• Tem cache?
• Cache é de página, objeto, CDN?
• Limpa cache a cada acesso?

Cache mal configurado é quase tão ruim quanto não ter cache nenhum.

Observe como o site reage a pequenas mudanças

Esse é um teste indireto, mas poderoso.

Pergunte:

• Atualizar um plugin quebra layout?
• Trocar tema é inviável?
• Qualquer ajuste exige “rezar”?

Se sim, o projeto não foi pensado para evoluir.

O padrão por trás de tudo isso

Projetos WordPress mal feitos geralmente compartilham a mesma origem:

• Pressa
• Preço baixo
• Soluções visuais
• Falta de base técnica

O site até funciona, mas vive no limite.

Importante: WordPress não é o problema

WordPress bem utilizado:

• É rápido
• Escala
• É estável
• Aguenta tráfego
• É fácil de manter

O problema nunca foi o CMS.
O problema é como ele é usado.

Identificar um projeto WordPress mal feito cedo:

• Evita retrabalho
• Evita prejuízo
• Evita desgaste com cliente
• Evita promessas que não podem ser cumpridas

E a melhor parte:
você não precisa de ferramenta cara, só de olhar técnico.

The post Como identificar um projeto WordPress mal feito em 10 minutos appeared first on Leonardo Nascimento | Engenheiro de Software.

Vamos começar com o óbvio que ninguém gosta de dizer

WordPress move uma fatia gigantesca da internet. Portais de notícias, sites institucionais, e-commerces, projetos governamentais e empresas milionárias usam WordPress em produção, com alto tráfego e performance.

Se o WordPress fosse o problema, esses sites simplesmente não existiriam.

O que existe, na prática, é outra coisa:
WordPress virou terra sem lei técnica.

O mito: “WordPress é lento”

Não.
Lento é o jeito que ele é montado.

WordPress, por padrão:

• Renderiza HTML no servidor
• Funciona muito bem com cache
• Escala com Cloudflare, CDN e NGINX
• Aguenta alto volume quando bem configurado

O que deixa o site lento não é o core. É o ecossistema mal utilizado.

O verdadeiro vilão: o “arrastar e soltar”

Construtores visuais como Elementor, WPBakery e similares não são ferramentas neutras. Eles impõem um modelo de desenvolvimento que cobra um preço alto — e quase sempre invisível para o cliente final.

O que realmente acontece por baixo do capô

Um site feito com drag and drop geralmente entrega:

• HTML inflado, sem semântica
• CSS duplicado, inline, desorganizado
• JavaScript carregado em excesso
• Dependência de dezenas de scripts globais
• Layouts quebradiços fora do editor

Tudo isso para resolver algo simples: posicionar bloco na tela.

O problema não é o plugin. É o conceito.

Construtores visuais vendem a ideia de “qualquer um pode criar um site”.
Tecnicamente, isso é verdade.
Profissionalmente, é um desastre.

Criar um site não é:

• Arrastar caixa
• Escolher fonte
• Mudar cor

Criar um site é:

• Pensar estrutura
• Performance
• SEO
• Manutenção
• Evolução futura

E nisso, drag and drop falha e falha muito.

SEO sofre (e muito)

Sites feitos com construtores visuais costumam ter:

• Hierarquia de headings quebrada
• Conteúdo diluído em divs sem sentido
• HTML difícil de interpretar para crawlers
• Tempo de carregamento alto no mobile

Depois, o cliente culpa:

• O Google
• O WordPress
• O servidor
• O SEO

Quando, na verdade, o problema nasceu no layout.

Manutenção vira um inferno silencioso

Todo site precisa evoluir.
E é aqui que o arrastar e soltar cobra a conta.

• Atualização quebra layout
• Plugin vira dependência crítica
• Migrar tema vira pesadelo
• Refatorar é praticamente impossível

O site funciona… até o dia que não funciona mais.

E quando dá problema, ninguém quer mexer.

“Mas é mais rápido desenvolver”

É mais rápido entregar.
Não é mais rápido manter.

Construtores visuais economizam horas no início e custam meses no futuro.
É dívida técnica disfarçada de produtividade.

A culpa também acaba sendo do cliente, que pretende lançar seu negócio em 1 semana e acha um ‘programador wordpress’ que entrega o projeto em 3 dias por menos de R$ 500 (História real)

Cansei de refazer sites em WordPress que foram utilizados ‘arrastar e soltar’, quando falo para o cliente que não da para aproveitar nada, ele ainda fica bravo comigo.

Na verdade não deveria estar fazendo essa crítica, poque é muito bom refazer esses sites, você refaz o tema, olha o banco de dados e tem lá mais de 245 tabelas para um portal de notícias regional ou até mesmo institucional (Mais uma história real), com certeza não saiu por R$ 500

WordPress bem feito é outra história

Quando WordPress é usado como deve ser:

• Tema enxuto
• PHP bem estruturado
• HTML semântico
• CSS organizado
• JS apenas quando necessário
• Cache correto
• Integração com CDN

O resultado é:

• Site rápido
• SEO limpo
• Fácil de manter
• Fácil de evoluir
• Profissional

Isso não aparece em tutorial de “site em 30 minutos”.

O mercado criou o problema — e culpa a ferramenta

O que estragou a reputação do WordPress não foi o WordPress.

Foi:

• Freelancer sem base técnica
• Agência vendendo atalho
• Cliente buscando preço, não solução
• Cultura do “funciona, então tá bom”

O arrastar e soltar só acelerou esse processo.

WordPress não é amador — o uso dele que é

WordPress é uma ferramenta poderosa.
Mas ferramenta boa na mão errada vira problema.

Se você quer:

• Performance
• SEO
• Escalabilidade
• Longevidade

Então pare de tratar WordPress como brinquedo visual.

Porque no fim, não é o CMS que define a qualidade do site.
É quem está por trás das decisões técnicas.

The post WordPress não é amador. Amador é o uso que fazem dele. appeared first on Leonardo Nascimento | Engenheiro de Software.

1. Claude.ai — o cérebro que resolve tudo
Criado pela Anthropic, o Claude é o rival direto do ChatGPT, e muitos juram que ele é ainda mais “humano”. Capaz de entender contextos complexos, revisar textos longos e até analisar documentos inteiros, o Claude virou o companheiro ideal para quem precisa de precisão e agilidade.

2. Ranked.ai — o impulso para o topo do Google
Essa IA é uma bênção para quem vive de SEO. Ela analisa, sugere e otimiza o conteúdo do seu site para conquistar posições valiosas nos resultados de busca. O melhor? Faz isso praticamente sozinha, com atualizações em tempo real.

3. Syllaby.io — vídeos prontos para bombar
Quer transformar roteiros em conteúdo de vídeo automático? O Syllaby faz isso com maestria. Ele cria, edita e entrega vídeos completos com narração e legenda, otimizados para TikTok, Reels e Shorts. Um aliado de peso para criadores e marcas.

4. Replit.com — código sem complicação
Mais do que um simples editor, o Replit é um ambiente de desenvolvimento guiado por IA. Ele escreve código, corrige bugs e até explica o que você está fazendo errado. É como ter um mentor de programação disponível 24 horas.

5. Manus.im — o superagente inteligente
Considerada uma das plataformas mais versáteis, o Manus é um agente de IA que centraliza tarefas: pesquisa, escrita, automação e até integração entre apps. Tudo num só lugar, com interface intuitiva e resultados rápidos.

6. Suno.com — música em segundos
Aqui, criatividade e tecnologia tocam juntos. O Suno permite criar faixas completas em poucos cliques, combinando estilos e vozes realistas. Ideal para trilhas de vídeos, podcasts ou simplesmente para quem quer experimentar novos sons.

7. Fliki.ai — texto que vira vídeo
Pegue um texto simples e veja ele se transformar em conteúdo visual dinâmico. O Fliki gera vídeos curtos, prontos para redes sociais, com narração natural e variedade de estilos. Um presente para quem quer produção rápida sem perder qualidade.

8. CloudXLR.com — o construtor de apps definitivo
Essa plataforma é o sonho de empreendedores e desenvolvedores. A CloudXLR usa IA para montar aplicativos completos, desde o design até a lógica interna, sem exigir uma linha de código manual.

9. Genspark.ai — o superagente da produtividade
Genspark é como um estagiário genial: escreve, pesquisa, planeja, organiza e ainda gera relatórios. Ele funciona como uma central de automação pessoal, perfeita para quem gerencia muitas tarefas ao mesmo tempo.

10. Fastread.io — eBooks na velocidade da luz
Produzir um livro digital nunca foi tão rápido. O Fastread cria, formata e finaliza eBooks a partir de poucos tópicos, com estrutura profissional e linguagem envolvente.

Bônus extra

• Perplexity — busca com IA que realmente responde, citando fontes.
• ElevenLabs — vozes artificiais extremamente naturais.
• Pika — geração de vídeos criativos com IA generativa.

The post 10 inteligências artificiais que você não pode ignorar em 2026 appeared first on Leonardo Nascimento | Engenheiro de Software.

Antes de decidir usar ou abandonar AMP, é preciso entender o problema que ele tentou resolver, quem o criou e o que mudou desde então.

O que é AMP

AMP (Accelerated Mobile Pages) é um framework criado para entregar páginas extremamente rápidas no mobile, com um conjunto restrito de HTML, CSS e JavaScript. A ideia central é reduzir ao máximo tudo que pode atrasar o carregamento.

Na prática, páginas AMP:

• carregam com menos recursos
• têm layout mais previsível
• priorizam conteúdo acima de scripts

O foco sempre foi experiência, não estética ou flexibilidade.

Quem criou o AMP e por quê

O AMP foi criado pelo Google, em parceria com outros players, por volta de 2015. Naquele período, a web mobile era lenta, pesada e inconsistente. Sites abusavam de scripts, anúncios e trackers, e a experiência no celular era ruim.

O AMP surgiu como uma resposta direta a isso: impor limites para forçar desempenho.

Para que o AMP realmente serve

O AMP serve para garantir carregamento rápido e previsível, especialmente em:

• notícias
• artigos
• conteúdos informativos
• páginas públicas e abertas

Ele nunca foi pensado para:

• aplicações complexas
• áreas autenticadas
• e-commerces completos
• experiências altamente interativas

Quando usado fora do escopo, costuma frustrar.

O auge do AMP e a associação com SEO

Durante um período, o AMP foi fortemente associado a vantagens de visibilidade, especialmente em carrosséis de notícias no mobile. Isso criou a percepção de que “usar AMP ajuda no ranking”.

Com o tempo, o Google deixou claro que não é o AMP em si que melhora SEO, mas sim os sinais de experiência (velocidade, estabilidade, interatividade). A partir daí, o AMP deixou de ser requisito e passou a ser apenas uma opção.

O que mudou nos últimos anos

Hoje, tecnologias modernas permitem alcançar desempenho semelhante ao AMP sem suas limitações:

• frameworks mais leves
• melhor uso de cache
• CDN em borda
• Core Web Vitals como métrica oficial

Além disso, o próprio Google passou a priorizar experiência medida, não tecnologia usada.

Resultado: AMP deixou de ser obrigatório e virou decisão estratégica, não padrão.

As principais vantagens do AMP

Quando bem aplicado, o AMP ainda entrega benefícios reais:

• carregamento quase instantâneo no mobile
• layout estável (baixo CLS)
• menor consumo de dados
• previsibilidade de performance

Para sites focados em leitura rápida, isso pode ser relevante.

As limitações (e por que muita gente abandonou)

O AMP impõe restrições que incomodam em projetos mais maduros:

• menos controle sobre JavaScript
• personalização limitada
• integrações mais complexas
• dependência maior de cache externo

Além disso, manter duas versões (AMP e não-AMP) aumenta custo de manutenção.

AMP vale a pena hoje?

Depende do tipo de site.

Pode fazer sentido se:

• o foco é conteúdo informativo
• o público é majoritariamente mobile
• a equipe é pequena
• performance ainda é um problema sério

Provavelmente não vale se:

• o site já tem bom desempenho mobile
• há muita interatividade
• o projeto depende de lógica complexa
• o time consegue otimizar sem AMP

AMP não é solução universal. É ferramenta específica.

Como medir engajamento em páginas AMP

Aqui está um ponto crítico: muita gente mede errado.

Métricas que fazem sentido

• tempo médio na página
• scroll depth
• taxa de retorno
• cliques em links internos
• eventos de leitura (ex.: 50%, 75%, 100%)

Essas métricas mostram se o usuário consumiu o conteúdo, não apenas se carregou rápido.

Atenção à fragmentação de dados

AMP pode gerar URLs diferentes e cache intermediário. Isso exige cuidado para:

• consolidar métricas corretamente
• evitar duplicação de sessões
• manter rastreamento consistente

Sem isso, o engajamento parece pior (ou melhor) do que realmente é.

AMP não substitui estratégia de performance

Um erro comum é usar AMP como atalho para não otimizar o site principal. Isso cria uma falsa sensação de qualidade.

AMP deve ser:

• complemento
• experimento
• ou solução pontual

Nunca muleta permanente.

Conclusão

O AMP nasceu para resolver um problema real da web mobile e cumpriu bem esse papel. Com a evolução das tecnologias e das métricas de experiência, ele deixou de ser obrigatório, mas não se tornou inútil.

Hoje, usar AMP é uma decisão consciente, não uma regra. Vale para alguns contextos, é desnecessário para outros. O que realmente importa é entregar uma experiência rápida, estável e previsível — com ou sem AMP.

The post AMP: o que é, para que serve, ainda vale a pena usar? appeared first on Leonardo Nascimento | Engenheiro de Software.

Mais do que uma nota colorida, o Lighthouse é uma ferramenta de diagnóstico. Saber usá-lo corretamente evita decisões erradas e otimizações inúteis.

O que é o Lighthouse

O Lighthouse é uma ferramenta automatizada de auditoria de páginas web. Ele analisa uma URL e gera um relatório com métricas e recomendações em cinco áreas principais:

• Performance
• Acessibilidade
• Boas práticas
• SEO
• Progressive Web App (PWA)

O objetivo não é apenas pontuar o site, mas mostrar onde estão os gargalos reais.

Onde o Lighthouse está disponível

Você pode usar o Lighthouse de várias formas:

• Chrome DevTools (nativo do navegador)
• Linha de comando (CLI)
• CI/CD (auditorias automatizadas)
• Ferramentas online baseadas no Lighthouse

Para a maioria dos casos, o DevTools já resolve bem.

Como rodar o Lighthouse pelo Chrome

1. Abra o site no Chrome
2. Pressione F12 ou Ctrl + Shift + I
3. Vá até a aba Lighthouse
4. Escolha o tipo de dispositivo (Mobile ou Desktop)
5. Clique em Generate report

Em poucos segundos, o relatório é gerado.

As métricas mais importantes (e o que elas significam)

Performance

Avalia tempo de carregamento e resposta da página. Algumas métricas-chave:

• LCP (Largest Contentful Paint)
  Mede quando o maior elemento visível aparece. Impacta diretamente a percepção de velocidade.
• INP (Interaction to Next Paint)
  Avalia a resposta do site às interações do usuário.
• CLS (Cumulative Layout Shift)
  Mede instabilidade visual (elementos “pulando” na tela).

Essas métricas fazem parte do Core Web Vitals, usados pelo Google como sinal de experiência.

Acessibilidade

Verifica se o site pode ser usado por pessoas com limitações visuais, motoras ou cognitivas. Exemplos de checagem:

• contraste de cores
• textos alternativos em imagens
• labels em formulários
• estrutura semântica do HTML

Mesmo que não seja um requisito legal em todos os casos, acessibilidade melhora usabilidade para todos.

Boas práticas

Aqui entram problemas mais técnicos, como:

• uso de APIs inseguras
• imagens com proporções erradas
• erros de console
• bibliotecas desatualizadas

É uma área que ajuda a manter o site saudável ao longo do tempo.

SEO

O Lighthouse não substitui ferramentas avançadas de SEO, mas valida o básico:

• meta tags essenciais
• indexabilidade
• uso correto de links
• estrutura mínima de conteúdo

Se o site falha aqui, dificilmente terá bom desempenho orgânico.

O erro mais comum: otimizar só para a nota

Muita gente usa o Lighthouse como competição de pontuação. Isso é um erro.

Um site pode ter nota 100 e ainda assim:

• carregar dados desnecessários
• ter arquitetura ruim
• sofrer em cenários reais de tráfego

O relatório deve ser lido como ferramenta de diagnóstico, não como objetivo final.

Mobile vs Desktop: sempre priorize mobile

O Google avalia sites com mobile-first indexing. Isso significa que:

• o relatório mobile é mais relevante
• problemas no mobile impactam mais SEO
• otimizações devem começar pelo mobile

Um site rápido no desktop e lento no celular está em desvantagem.

Lighthouse em produção e CI/CD

Em projetos mais maduros, o Lighthouse pode rodar automaticamente:

• antes de deploy
• após mudanças críticas
• em pipelines de CI/CD

Isso ajuda a evitar regressões de performance e garante que melhorias não sejam perdidas com o tempo.

Limitações do Lighthouse

Apesar de poderoso, o Lighthouse tem limites:

• roda em ambiente controlado
• não reflete todos os cenários reais
• não substitui métricas de usuários reais (RUM)

O ideal é combiná-lo com dados reais de uso, como relatórios de experiência de campo.

Quando o Lighthouse faz mais diferença

Ele é especialmente útil para:

• identificar gargalos iniciais de performance
• validar mudanças estruturais
• educar times sobre impacto técnico
• criar baseline de qualidade

Não é uma bala de prata, mas é um excelente ponto de partida.

O Lighthouse não serve para “tirar nota alta”, mas para entender como o site se comporta do ponto de vista do usuário. Quando usado com critério, ele direciona otimizações que realmente fazem diferença.

Ignorá-lo pode custar performance, experiência e visibilidade. Usá-lo mal pode custar tempo. O valor está em interpretar os dados, não apenas executá-los.

The post O que é Lighthouse e como usar para melhorar seu site appeared first on Leonardo Nascimento | Engenheiro de Software.