Por que um novo site?

Muitos de vocês devem se perguntar: "Por que diabos a Drope decidiu criar um site novo do zero?"

Pode parecer apenas uma decisão ousada (com certeza masoquista), mas depois de algum tempo, tornou-se uma questão de sobrevivência. Chegar onde estamos hoje, em 2025, foi muito mais complicado do que a interface bonita do novo site deixa transparecer.

Esta é a história técnica de como fomos do "padrão de scanlation" para uma arquitetura feita sob medida.

O Pesadelo da Performance

O primeiro sinal de que algo estava errado era o desempenho. Tínhamos uma dependência tóxica da nossa CDN (Content Delivery Network).

Se desativássemos o cache da Cloudflare por um minuto, o site se arrastava. Demorava segundos para carregar a página de uma obra; medir o tempo de carregamento de um capítulo era praticamente impossível. LCP? Piada total! A culpa? Uma mistura de PHP legado e arquitetura ineficiente.

O Madara, escrito em versões mais antigas do ecossistema WordPress, depende pesadamente de requisições AJAX para tudo: contagem de visualizações, histórico de leitura, favoritos. Cada clique de um usuário disparava múltiplas chamadas ao servidor, iniciando o core do WordPress repetidas vezes.   

Vendo isso, muitos diriam: "É só aumentar o servidor! Mais CPU, mais RAM, SSD mais rápido!"

Nós fizemos isso. Adivinhem? A melhora foi mínima. O gargalo não era hardware; era software.

O Vilão Oculto: wp_postmeta e a "Gambiarra" dos Dados

Aqui entra a parte técnica que justifica nossa insônia. O problema real estava no banco de dados.

O WordPress utiliza um modelo EAV (Entity-Attribute-Value) na tabela wp_postmeta para guardar qualquer dado que não seja título ou corpo do texto.   

• Quer salvar o autor do mangá? wp_postmeta.
• O artista? wp_postmeta.
• O status da obra? wp_postmeta.
• Data de lançamento? wp_postmeta.

Imagine uma biblioteca com 3.500 capítulos. Agora imagine que, para montar uma única página, o banco de dados precisa varrer milhões de linhas nessa tabela desorganizada, fazendo JOINs pesados para encontrar cada pedacinho de informação.

E quando precisávamos de relacionamentos complexos, como Gêneros, Temas e Formatos? O WordPress nos força a usar Taxonomias (É esse nome difícil mesmo). Para um blog, "Tag" funciona. Para um site de mangá com dados relacionais complexos, isso é, no bom português: gambiarra.   

Se a gambiarra fosse boa, ela seria o padrão. O resultado eram queries SQL lentas, impossíveis de otimizar e um cache que nunca funcionava direito porque o sistema não sabia diferenciar o que era estático do que era dinâmico.

O Desafio de I/O: Mais de 70.000 Imagens

Um blog médio tem, talvez, 750 imagens. A Drope, em 2023, tinha cerca de 3.500 capítulos. Multiplique isso por uma média de 20 páginas por capítulo: estamos falando de mais de 70.000 imagens.

O WordPress não possui um sistema inteligente de roteamento de imagens. Ele entrega a imagem crua, do jeito que está no disco. O I/O (Input/Output) do nosso disco vivia no vermelho (AWS Pipocava alerta de uso de Disco).

O Madara oferecia uma solução: armazenamento externo no Amazon S3. Parecia a salvação, mas era outra armadilha. O código nos prendia ao ecossistema da AWS. E cá entre nós, o S3 é maravilhoso até você receber a fatura de tráfego de saída (egress). Tentar adaptar o código para provedores mais baratos e compatíveis era uma luta constante contra um código que não controlávamos. 

A Parede Funcional: Gestão de Grupos e Usuários

Além da performance e das imagens, tínhamos uma necessidade de negócio que o WordPress simplesmente não conseguia atender: Multitenância.

Precisávamos de um sistema robusto de Grupos.

• Queríamos que grupos parceiros pudessem gerenciar suas próprias obras.
• Precisávamos de hierarquia: Uploader, Moderador, Administrador de Grupo.

O sistema de usuários do WordPress é linear (Admin > Editor > Assinante). Tentar implementar uma gestão complexa de grupos em cima disso exigia plugins pesados de "Membership" ou "Multi-Author" que tornavam o banco de dados ainda mais lento e abriam brechas de segurança.   

Estávamos limitados pelo caminho que o desenvolvedor do tema escolheu. Queríamos adicionar uma feature exclusiva? Impossível, pois a complexidade de integrar ao código "complexo" do tema e a forma como o WordPress gerencia plugins tornava qualquer alteração um risco de quebrar o site inteiro.

O Renascimento (2025)

Resistimos de 2019 a 2023. Lutamos contra o cache, pagamos faturas altas de servidor e remendamos o código o máximo possível.

Até que, em um momento decisivo, eu cansei de receber alertas de "Site Offline" no meio da madrugada. Desliguei o site. A decisão foi tomada: faríamos do zero.

E aqui estamos, em 2025. Construir uma plataforma própria, sem saber exatamente por onde começar, foi uma jornada insana. Foi um percurso incansável por novas linguagens de programação, frameworks modernos, decisões de arquitetura e muita, muita reescrita de código.

Mas o resultado é o que vocês veem hoje. A Drope agora roda em um código que é nosso. O banco de dados foi arquitetado para mangás, não para blogs. As imagens são servidas por um roteador inteligente que não custa um rim. E o sistema de grupos funciona nativamente.

A partir da mão daquele que vos escreve, e com o auxílio pontual de duas pessoas fundamentais, a Drope chegou até aqui. Hoje, vemos um novo dia, com uma nova identidade visual e, finalmente, a liberdade que sempre buscamos.