🚀 Arquitetura WordPress Headless com Docker, Redis Streams, MongoDB e Next.js — do zero ao deploy

Neste tutorial completo eu mostro como transformar o WordPress num CMS headless de verdade, distribuindo o conteúdo para MÚLTIPLOS frontends através de uma fila de eventos. Nada de frontend chamando a API do WordPress a cada request: o WordPress publica eventos numa fila (Redis Streams), workers consomem esses eventos e gravam no MongoDB, e os frontends (PHP e Next.js) leem apenas do Mongo. Resultado: rápido, desacoplado e escalável para vários clientes. Se você trabalha com WordPress, Docker, microsserviços ou está estudando arquitetura de software orientada a eventos, esse vídeo é pra você. Tudo rodando com Docker Compose e Traefik com HTTPS. ⬇️ Capítulos, stack e links ⬇️ 🧠 O QUE VOCÊ VAI APRENDER ✅ Subir WordPress + MySQL 8 com Docker Compose ✅ Reverse proxy com Traefik, HTTPS automático e redirect de HTTP ✅ Adicionar phpMyAdmin para administrar o banco ✅ Criar imagens Docker customizadas (extensões PHP redis e mongodb via PECL) ✅ Escrever um mu-plugin que publica eventos de post no Redis Stream ✅ Modelar eventos published / updated / trashed numa fila única ✅ Construir um worker em Node.js (ioredis + mongodb) com consumer groups ✅ Garantir entrega com ack e reprocessamento via XAUTOCLAIM ✅ Sincronizar posts no formato _embed da REST API do WordPress ✅ Frontend em PHP lendo direto do MongoDB ✅ Frontend em Next.js (App Router) com rotas /categoria/post/ ✅ Página de categorias e arquivo de categoria ✅ Boas práticas de SEO em permalinks e rotas dinâmicas 🛠️ STACK / TECNOLOGIAS • WordPress (headless) + MySQL 8 • Docker e Docker Compose • Traefik (reverse proxy + TLS) • Redis 7 (Redis Streams como fila de mensagens) • MongoDB 7 (banco de leitura) • Node.js 20 (worker e Next.js) • Next.js 14 (App Router, Server Components, output standalone) • PHP 8.3 (Apache) • phpMyAdmin ⏱️ CAPÍTULOS 00:00 Introdução: WordPress como CMS (não só blog) 02:00 CMS x site: por que todo sistema precisa gerenciar conteúdo 05:00 A ideia: desacoplar CMS, aplicação e front-end 06:40 Objetivo da stack e preparação do ambiente (Traefik local) 08:00 Estratégia de rotas: WordPress só no /wp- e o site na raiz 08:40 Subindo a stack WordPress + MySQL 8 com Docker Compose 11:30 Instalando o WordPress 12:20 Configurando o Traefik (labels, rede www, TLS) 20:40 Roteando só /wp- para o WordPress (PathRegexp) e o debug do 404 27:20 Era acesso por HTTP: redirect forçado para HTTPS 28:30 phpMyAdmin e o verdadeiro gargalo do WordPress (tabela postmeta) 31:40 Editor Classic e a estratégia headless 33:20 Espelhando o WordPress para outro banco (MongoDB) 35:40 mu-plugins e o primeiro front-end em PHP consumindo a API interna 41:40 Segundo front-end em Next.js consumindo a API 44:50 Adicionando Redis + MongoDB e sincronizando os posts (formato _embed) 47:50 Instalando tema/demo e importando conteúdo de teste 53:40 Sincronização manual e build das imagens (extensões Redis/Mongo) 01:01:40 Desenhando a arquitetura: CMS → fila → worker → client 01:08:30 Stack no ar e corrigindo o fluxo (worker deve consumir a fila) 01:10:50 Por que fila + workers (multi-cliente) e não o WP gravando direto no Mongo 01:13:40 Plugin publisher e a extensão Redis na imagem do WordPress 01:16:20 Por que consumir da API: shortcodes e HTML já processado 01:21:20 Testando os eventos no Redis e no worker 01:24:40 Bug do delete de rascunho e a correção (published / updated / trashed) 01:30:10 Validação e por que a postmeta escala exponencialmente 01:33:20 Next.js como front principal e permalinks /categoria/postname 01:36:20 Criando a página de categorias 01:38:30 Normalizador, agregador e ecossistema multi-CMS 01:45:40 Página de categoria funcionando e recap da arquitetura 01:50:00 SEO, segurança e "parece WordPress, mas não é" 01:53:00 Sincronizar outros tipos de post e o uso de hooks 01:55:00 Galeria de imagens e por que o HTML vem processado 01:59:00 Conclusão: dominando o WordPress como CMS desacoplado 02:00:40 Subindo no GitHub, commits organizados e README 02:02:00 Encerramento 💡 POR QUE ESSA ARQUITETURA? Enviar o conteúdo do WordPress direto para o banco de cada cliente é inviável quando você tem muitos consumidores. Com uma fila de eventos, o WordPress publica UMA vez e cada cliente consome no seu ritmo, com seu próprio consumer group, replay e tolerância a falhas. É o padrão usado em sistemas orientados a eventos (event-driven), CQRS e read models. Você aprende na prática como aplicar isso sem complicar. 📦 RECURSOS E LINKS 🔗 Código-fonte no GitHub: https://github.com/albreis/complex-wo... 🔗 Documentação do Docker: https://docs.docker.com 🔗 Traefik: https://doc.traefik.io/traefik/ 🔗 Redis Streams: https://redis.io/docs/latest/develop/... 🔗 MongoDB: https://www.mongodb.com/docs/ 🔗 Next.js: https://nextjs.org/docs 🔗 WordPress REST API: https://developer.wordpress.org/rest-... #WordPress #Docker #DevOps #NextJS #MongoDB #Redis #PHP #Headless #Microservices #Programação #DesenvolvimentoWeb #FullStack #ArquiteturaDeSoftware #Traefik #RedisStreams