Cinco anos atrás escrevi este post descrevendo como era a arquitetura do Grails Brasil (hoje Groovy e Grails Brasil). As coisas caminharam bastante desde então: de um código fonte que tinha como objetivo atender um único site (Grails Brasil), pouco a pouco este evoluiu para que se tornasse uma solução capaz de atender qualquer comunidade.
Ao lançarmos o Spring Brasil demos o primeiro passo no que diz respeito a este objetivo: era essencialmente o código fonte do Grails Brasil com uma série de pequenas modificações (essencialmente a remoção de tudo o que era específico apenas daquele site). Já no caso do JavaScript Brasil demos o passo quase derradeiro: é o mesmo código fonte do Spring Brasil: todas as customizações (especialmente visuais), entretanto, passaram a ser o resultado de mudanças na configuração.
Acho que é interessante contar a história técnica por trás deste projeto (ela descreverá sua arquitetura). Curiosamente, não temos um nome para este código fonte: antes era “Grails Brasil”, hoje o chamamos de “Komunidade” ou o nome do site no qual estamos trabalhando.
A história
O início em PHP
A primeira versão do Grails Brasil veio em 2008 e era na realidade uma instalação do phpBB. Sim, você leu certo: o Grails Brasil era um site escrito em PHP. O criei para aprender Grails e o phpBB era uma solução muito interessante na época: fácil de instalar (fiz isto usando um assistente da Hostnet na hora do almoço) e manter. Além disto, era o que precisávamos na época: um fórum básico.
Esta solução nos atendeu bem por um ano ou dois. A hospedagem era relativamente barata, mas com o tempo foi ficando mais cara por dois motivos:
- A comunidade cresceu bastante e sempre estávamos superando nosso limite de banda.
- SPAM quase nos destruindo: gastava uma boa parte do meu dia apagando SPAM do site.
Em um primeiro momento fiz modificações no código do phpBB para reduzir estes problemas. Não tive bons resultados e por um tempo pensei seriamente em matar o projeto.
Segunda fase: primeira versão em Grails
Lá por 2008, 2009 tive meu primeiro contato com servidores cloud que passaram a se mostrar como uma alternativa bem mais viável (plano free tier da AWS pra ser mais preciso). Até então hospedagem Java era ou muito cara (pra mim) ou muito limitada (precisava enviar um WAR para o serviço que oferecia um Tomcat compartilhado, algo muito tosco).
Foi a oportunidade para poder finalmente ter a primeira versão em Grails do site. Dois objetivos me guiaram para esta mudança:
- Meu custo com hospedagem deveria ser menor.
- O problema do SPAM deveria ser definitivamente resolvido.
Foi escrita então esta primeira versão do site em Grails (versão 1.3.7, que foi usada até ano passado ou retrasado se não me engano – hoje usamos a versão 3.2.8). Dado que serviços como AWS costumam cobrar por processamento, foi o momento ideal para que eu pudesse otimizar ao máximo meu código (o que me levou a um conhecimento bem mais profundo da linguagem Groovy e da própria JVM).
E nisto foram tomadas uma série de decisões que são refletidas no código até hoje:
- Dado que já existia uma base de posts vinda do phpBB, e este usa uma sintaxe chamada bbCode no armazenamento dos posts, a próxima versão do site deveria manter esta compatibilidade (até hoje usamos bbCode para escrever os posts).
- As buscas não deveriam tocar o banco de dados: sendo assim adotamos o Lucene como nosso motor de indexação usado em todas as nossas consultas (já notou como são rápidas?).
- Dado que meu objetivo era reduzir custos, e minha instância no free tier da AWS tinha 612 Mb de RAM, neste mesmo servidor deveriam ser executados o MySQL e o Tomcat. Logo o sistema poderia consumir, no máximo, 300 Mb de RAM (consome isto até hoje).
- O site tinha de ser mais rápido que o phpBB (consegui, é ordens de magnitude mais rápido). Logo o que pudesse ser feito assincronamente deveria ser feito desta maneira (por isto e-mails não são enviados na hora, mas sim esporadicamente, assim como atualização de acessos e pontuação dos membros).
- A esmagadora maioria dos acessos ao site são para simples consulta (10% se registram e menos ainda chegam a postar conteúdo), sendo assim SEO é prioridade (idem a busca).
E assim surgiu o Grails Brasil escrito em Grails. Uma série de medidas foram tomadas para atingir estes objetivos, todas elas descritas neste antigo post (e as adotamos ainda hoje).
Terceira fase: Spring e JavaScript Brasil
Até 2015 o código do Grails Brasil se manteve essencialmente o mesmo, apenas com pequenas correções. A partir de 2016 começaram mudanças mais significativas.
A primeira delas dizia respeito à atualização do próprio Grails: passamos a usar a versão 3 e, pouco a pouco, fomos migrando até a versão 3.2.8, usada hoje. Por que levou tanto tempo para fazer este upgrade? A versão antiga me atendia muito bem. Uma boa decisão tomada lá atrás? Ter usado pouquíssimos plug-ins, o que tornou o upgrade muito fácil (em questão de horas estávamos na versão 3.0 do Grails). Além disto estava claro que precisávamos atualizar o código fonte para termos algo durável (Java 6??? Bora pro 8!).
Já fazia um tempo que queríamos criar novas comunidades, então era também a hora de podar o código fonte, removendo tudo aquilo que só fazia sentido no Grails Brasil do novo código. Foi ótimo por que conseguimos otimizar ainda mais o que já tínhamos.
(hoje como consequência temos duas bases de código: uma para o Grails Brasil, outra que atende as outras comunidades para que pudéssemos manter as funcionalidades para os membros atuais do site)
Novos objetivos arquiteturais
Modificações do site em tempo de execução
Ao lançar novas versões do site sempre havia momentos nos quais me deparava com pequenos problemas de layout, conteúdo textual ou JavaScript nos quais detectava problemas logo após ter implantado a solução. Aí era necessário gerar um novo WAR e realizar todo o processo de deploy.
Isto ocorria por que sempre havia um ou outro ponto de configuração que ficava no próprio código fonte (o próprio HTML gerado pelo site, por exemplo, pode ser visto desta forma). Hoje todas as configurações encontram-se externalizadas no banco de dados. Com isto, se queremos modificar, por exemplo, o rodapé do site após a versão ter ido pro ar, hoje é possível.
Erros de layout devido a problemas no CSS? Ok, podemos mudar também. Apenas a título de curiosidade, o JavaScript Brasil passou por umas 20 correções de layout de ontem até hoje (23/8/2017). Sabe quantos deploys foram feitos? 1.
Além disto o conteúdo que aparece nas laterais do site, rodapé e cabeçalho também podem ser modificados hoje com o site em execução, o que nos permite trocar anúncios de uma forma muito mais ágil.
Não só isto: configurações de tarefas agendadas, acesso às integrações essenciais (e-mail, redes sociais e no futuro até mesmo a conexão com o SGBD) são hoje trocadas a quente.
Criação rápida de novas comunidades com o mesmo código fonte
O objetivo é que o “Komunidade” seja como o WordPress. Você baixa a distribuição, configura o acesso ao banco de dados, escolhe um tema e voilá, tá criado um novo blog ou, em nosso caso, uma nova comunidade.
A versão atual é exatamente assim. Pegamos o código fonte, definimos a configuração de acesso ao banco de dados, geramos o WAR, criamos um tema, configuramos no banco de dados do projeto os detalhes da comunidade (seu nome, regras de conduta, quais links são expostos, aonde ficam nossos arquivos de template de e-mail e temas visuais e mais uma série de outros detalhes), instalamos no Tomcat e pronto: uma nova comunidade surge.
Levou algo em torno de umas 4 horas para termos uma primeira versão aceitável do JavaScript Brasil (e nós nem sequer tocamos no código fonte do projeto).
Tornar a abertura do código fonte algo viável
Este tem sido o objetivo já faz algum tempo. Infelizmente ainda há informações no código fonte atual que não devem ser publicadas. Este é o principal motivo por que ainda não existe um repositório no GitHub com o código do Komunidade.
Mas posso dizer que o último release não deu mais um passo nesta direção, mas sim um salto quântico. A esmagadora maioria das informações que mencionei acima não existe mais. O objetivo agora é tornar este código fonte o mais fácil possível de ser mantido E entendido por novos colaboradores.
Mais do que tornar o código fonte mais legível, temos de ter uma distribuição do “Komiunidade” que possa ser usada também por não programadores. Algo como o WordPress.
(diga-se de passagem, uma pessoa que não sabe programar é que fez o tema do JavaScript Brasil, absolutamente sozinha)
Também falta melhorar a documentação do projeto: código Grails é muito fácil de ser entendido, mas não é o suficiente (nunca acreditei naquele papo de “meu código é minha documentação”).
Então, aos que sempre me pedem acesso ao código fonte o que posso dizer neste momento é isto: será eventualmente aberto, mas de uma forma correta e em grande estilo, não por pressão.
O futuro
Lá em cima mencionei que hoje temos duas bases de código: “Grails Brasil” e “Komunidade”, certo? Isto é temporário pois o objetivo é ter apenas uma. Mas como fazer isto se no código do Grails Basil há tanta coisa que só faz sentido nele?
Já estou trabalhando em uma arquitetura de plug-ins para este projeto (WordPress sempre é inspiração). Sendo assim, tudo aquilo que era específico do Grails Brasil será transformado em um pequeno módulo, que possa ser instalado em uma instância do “Komunidade”.
Com isto é possível ter seções distintas em instalações separadas do Komunidade. É possível, por exemplo, termos uma seção em uma instalação do site que seja na realidade um plug-in. O core será bastante diminuto, e a seu redor os plug-ins orbitarão: tal como ocorre no Eclipse, Netbeans e, claro, no WordPress também.
No que diz respeito ao frontend, ainda temos receio a respeito de uma grande mudança, tal como a adoção de um framework JavaScript ainda tenho algum receio pois um dos nossos objetivos é ter código duradouro e, sinceramente, ainda hoje não vi soluções que tenham passado no teste do tempo (com exceção do jQuery talvez).
E enquanto isto vamos evoluindo pouco a pouco o código que temos. Esta é a história do projeto até agora, grandes novidades virão em breve como sempre. Espero que tenham gostado.
E se inscrevam no Spring Brasil e JavaScript Brasil, pois o principal objetivo por trás dos dois projetos é criar discussões bem acaloradas sobre estes temas!
Deixe uma resposta