Desenvolver um Headless CMS do zero não é apenas sobre CRUDs; é sobre gerenciar complexidade, garantir consistência visual em escala e tomar decisões técnicas baseadas em ROI. O Rush CMS nasceu de uma necessidade minha, e de mercado. Mas sua fundação foi construída sob os princípios de Design Systems e Clean Architecture.

Neste post, abro o capô das decisões de design e infraestrutura que sustentam o projeto hoje em produção. Prepare-se para ver o motivo de que cada peça do motor foi pensada. Devo lembrar que o Rush CMS - por enquanto - é um projeto fechado, de uso próprio.

Conheça a anatomia do Rush CMS

Antes de falar sobre as decisões, vamos aprofundar sobre o design system de forma pura e clara. Se você quiser se aprofundar sobre o que o Rush faz, acesse o site oficial:

O que é usado?

• Gateway
  • Interface em Filament
  • API agnóstica com endpoints protegidos, entrega de JSON puro para o front-end
• Engine
  • App com Laravel 12 + PHP 8.4 (Strict Typing + PHPStan lvl5)
  • Performance com Laravel Octane (Swoole)
• Data Persistence
  • PostgreSQL (JSONB para flexibilidade de Collections)
  • Redis para queues e cache
• DevOps
  • Docker
  • Coolify
  • Hetzner
• CI/CD
  • GitHub Actions rodando 600+ testes (Pest)
  • Pint
  • PHP Stan
  • Frontend Build

Background e Workers

• Job de Imagem: Upload no S3 → Resize Worker → WebP converter → CDN
• i18n Engine: O CMS é i18n-first, nativamente ele suporta vários idiomas nos conteúdos, utilizando Spatie integrado aos Models para tradução on-the-fly
• Integrações:
  • PI interna de consumo para os websites
  • Google Analytics Oauth2
• *Observability & Reliability:
  • Google Analytics
  • Webhooks de deploy (para sites estáticos)
  • Tripla camada de backup (Spatie, Hetzner, Coolify)

Ok, agora que você já sabe o que ele tem, vamos entender alguns motivos do por que ser feito dessa forma.

O Design System como Pilar de Escalabilidade

No tempo de Dante era comum começar pelo banco de dados. Eu comecei pela consistência. Para um CMS multi-tenant, o Design System não é sobre "estética", é sobre eficiência operacional. Primeiro eu tenho que documentar tudo o que eu preciso, antes de colocar a mão em qualquer linha de código.

Sobre Filament e Tailwind

Utilizei o ecossistema do Filament para herdar um sistema de componentes robusto para o painel de controle. Isso permitiu focar no que é core para o negócio: a criação de Custom Blocks, Collections, Databases.

Aqui eu faço uma confissão: eu gostaria MUITO de desacoplar completamente o frontend e usar React puro, mas seria uma péssima decisão para o que projeto necessitava, então - com uma lagrima nos olhos, e os pés no chão - segui com Filament, uma decisão técnica baseada em ROI, garantindo acessibilidade e usabilidade nativas sem reinventar padrões de UI estáveis.

Contract Driven Design

A inteligência do Design System está no Schema da API. O usuário pode criar dezenas de blocos customizados, mas a responsabilidade de "entender" e renderizar esses blocos é do front-end desacoplado.

O CMS dita a estrutura do dado, e o consumidor da API implementa a visualização. Esse contrato rigoroso é o que garante que novos tipos de conteúdo possam ser criados sem quebrar a integridade visual do produto final. É uma excelente forma do desenvolvedor front-end poder ter um site extremamente dinâmico através do painel de controle, e fazer o front-end com todas as suas preferências pessoais.

Decisões Técnicas e Trade-offs

Aqui, meu foco foi minimizar o Time-to-Market sem comprometer a qualidade.

Multi-tenancy e Isolamento Zero Trust

A arquitetura de multi-tenancy foi implementada com foco total em desacoplamento entre tenants via a package Filament Shield. Não existe um "Super User" com acesso irrestrito aos dados de todos os clientes por padrão.

Se o meu acesso for revogado pelo administrador de um site, o isolamento é total. É uma escolha de design que prioriza a soberania de dados do cliente sobre a conveniência técnica do desenvolvedor. Para acompanhamento contratual, os únicos acessos que tenho são: espaço ocupado no S3 e API requests.

Performance com Laravel Octane

Essa decisão pode ser lida de várias formas, como antecipada ou correta. Por que ela é correta? O Rush CMS foi projeto para atender diversos sites em tempo real, tanto SSR, ISR ou SSG, e uma refatoração da plataforma com 100+ sites rodando simultaneamente traria mais trabalho que já deixar pronto agora. Mesmo que eu não fosse usar Octane agora, eu já teria que escrever o sistema pronto para ele, com todos os cuidados dos dados necessários, o que mostra ainda mais o sentido em já trazer velocidade o quanto antes.

Por isso, a transição para um servidor in-memory com Octane no commit #247 foi estratégica, ela pavimenta o caminho para escalas maiores, garantindo que o motor do CMS responda com latência mínima conforme o volume de requisições aumenta.

Postgres e JSONB

A flexibilidade exigida por um CMS de coleções dinâmicas pede esquemas mutáveis. O uso de JSONB no Postgres permitiu unir a potência de ferramentas NoSQL com a segurança e integridade do ecossistema relacional do Eloquent ORM.

Qualidade de Software e Feedback Loops

Um sistema em produção com clientes reais não pode ser frágil.

Estratégia de Testes

O Rush CMS conta hoje com 600+ testes automatizados (Pest PHP), ainda está longe da totalidade, mas cobre todo o "core system". O foco atual não é cobertura por vaidade, mas a proteção da lógica de precificação, permissões e integridade do multi-tenancy.

Integridade do Código

Atualmente em PHPStan Level 5, com roadmap para o Level 8/9 (a mão coça pra fazer isso logo hahaha). Manter o código tipado e analisado é o que me permite fazer deploys diários com maior confiança (utilizo CI/CD desde o dia 1).

Image Pipeline

Implementei um sistema de otimização WebP via S3 logo no início. Refatorar pipelines de mídia após ter milhares de arquivos é um pesadelo de custos e migração; resolvi isso como uma feature de core logo no começo, assim eu garanto um S3 magrinho e evito a inevitável refatoração no futuro.

Lições de ROI

O que eu faria diferente? É importante aprender com os próprios erros, para não repetir depois! Os dois erros que vou citar são iguais, em aplicações diferentes, eu tentei reinventar a roda:

1. i18n: Tentei criar um sistema de tradução próprio antes de migrar para o Spatie Translatable. Lição: Use soluções battle-tested para problemas comuns.
2. Analytics Interno: Construí um motor de analytics completo antes de perceber que o foco do produto deveria ser o CMS, não o monitoramento. Substituí por integrações nativas (Google Analytics/OAuth2), economizando horas de manutenção.

O que estou achando do Rush, até agora?

O Rush CMS é um testemunho de que velocidade e qualidade não são mutuamente exclusivas, desde que você tenha um Design System sólido e uma estratégia de testes rigorosa. Atualmente, o projeto segue evoluindo, já com planos de médio, longo e longuíssimos prazos.

O feedback dos clientes que estão testando a plataforma estão positivos, há muito trabalho pela frente!