Dia 1º de Março a gente lançou o novo site da Alura. Além do fantástico novo visual, muita gente reparou nos diversos outros detalhes: subdomínio separado da plataforma de aulas, a performance fenomenal do site novo, o design responsivo etc. Neste post quero discutir um pouco da Arquitetura do novo site e como chegamos nesses resultados.
A decisão de separar o site da plataforma
Historicamente, a Alura todo era um grande monolito escrito em Java. Isso inclui o site de vendas, páginas de marketing, a plataforma de cursos, o sistema de pagamentos e até códigos do MusicDot. É ruim porque temos muita gente mexendo no código, porque o deploy é demorado, a disponibilidade é uma só (se cair, cai tudo de uma vez).
Na nova reformulação, resolvemos quebrar um pouco. O site externo agora é um projeto separado da plataforma de cursos. Em www.alura.com.br fica o site externo, com foco em apresentar e vender a Alura, em SEO, em marketing. E no cursos.alura.com.br fica a plataforma de cursos, focado em apresentar as aulas, exercícios, fóruns etc.
O Google App Engine
A Alura roda na Amazon desde o início. Temos bastante coisa feita na infra de lá. Usamos EC2 com uma AMI própria. S3 com alguns arquivos estáticos. Os dados ficam no RDS. O deploy foi automatizado pra rodar lá. Nos serve bem, dada a complexidade do projeto.
Mas é bastante complexo e difícil. Nossos deploys não são tão ágeis. E quando decidimos quebrar o site em um projeto separado, sabíamos que não iríamos precisar de infra complexa. Não só isso: o site precisa de mais agilidade nas mudanças, por ter um foco maior em marketing (ex. subir campanhas promocionais com agilidade).
Há 7 anos que usamos o Google App Engine na Caelum. E com muito sucesso. Na minha opinião, é o único PaaS de verdade no mercado. Escalabilidade barata e 100% transparente. Zero trabalho de manutenção de infra. Deploy instantâneo com escalabilidade infinita. Resolvemos ir para o GAE no novo site da Alura.
O PHP
A plataforma de cursos da Alura é em Java. O site da Caelum, que roda no GAE, é em Java. A maioria dos nosso projetos e da nossa experiência por aqui é em Java. Mas decidimos criar o novo site da Alura em PHP.
Nosso maior problema com o site externo, como falei, é que ele precisa ser ágil para mudanças da equipe de marketing e design. Subir campanhas com facilidade, mudar o design do site para comemorar certas datas, testar novas abordagens com foco em marketing e conversões.
E o Java não é conhecido por ser simples. Tem uma curva de aprendizado. O ambiente de desenvolvimento é mais complexo. Subir o servidor é demorado. Fazer um deploy é custoso. O Java é robusto e certamente a melhor decisão pra nossa plataforma de cursos. Mas não resolveria o novo site.
Optamos pelo PHP porque o GAE tem suporte e por ele ser simples e acessível a todo mundo da equipe - backenders, frontenders, marketeiros, designers etc. Executar o projeto na máquina do designer é tão simples quanto rodar php -S na pasta do projeto. E instantâneo.
A arquitetura
Nosso requisito principal era o projeto ser acessível para toda equipe - 1 clique pra executar, servidor instantaneamente no ar, - e simples para colocar no ar - 1 clique pra deployar, infra toda pronta e escalável. O AppEngine com o PHP caiu como uma luva.
Mas temos outros requisitos importantes. O site precisa ser rápido, bom de SEO e integrar com o backend principal da plataforma de cursos da Alura. Algumas coisas aí na nossa stack atrapalharam.
Para manter a simplicidade, decidimos não ter um build-step no projeto. Isso quer dizer que o código que escrevo é o que eu rodo local e é o que eu deployo em produção. Mas isso impediu a gente de usar gulp para otimizações básicas como minificação, concatenação, autoprefixer etc. Então implementamos várias dessas otimizações de forma transparente no backend com PHP.
Usamos o mrclay/minify para minificar CSS, JS e HTML. Escrevemos um helper em PHP para adicionar prefixos no CSS automaticamente. E implementamos também em PHP um mecanismo simples de concatenar arquivos CSS/JS e de criar sprites SVG.
Além disso, essencial para nós foi o suporte a HTTP/2 do App Engine (e do QUIC). Com isso tira-se o foco de otimizações básicas como simples concatenações. E entram em cena recursos ultra bacanas como Server Push. Isso tudo merece um post a parte para mostrar o impacto de se usar HTTP/2.
Integração entre sistemas
Um último ponto que vale a pena destacar é que o site da Alura não possui banco de dados,um admin ou back-end complexo. Todo o cadastro de dados, como as informações dos cursos, continua na plataforma de cursos. O site externo consome esses dados através de uma nova API REST que a plataforma expõe.
Por exemplo, para saber os valores atuais dos planos de assinatura, chamamos https://cursos.alura.com.br/api/planos.
No lado do site da Alura, fazemos um GET para essas URLs de tempos em tempos usando Cron jobs e Task queues do App Engine. Os dados são então salvos no Google Cloud Storage e cacheados no Memcache do GAE para acesso rápido.
Mais sobre o projeto
O projeto do novo site da Alura começou a sair do papel no final de 2015 com a criação e design. Muitas pessoas participaram da implementação. Na equipe de front-end estavam Fernando Stefanini, Jana Paradiso e Yuri Padilha. No back-end e APIs, Philippe Ehlert, Rodrigo Turini, Felipe Oliveira e Caio Incau. Além de Caio Souza na reorganização do conteúdo e dos designers Thiago Vilaça e Fabio Gushiken.
Muitas outras coisas bacanas aconteceram no projeto. Fizemos uma implementação responsiva mobile-first, usando flexbox no CSS, sistema de ícones em SVG. Fizemos várias otimizações para ficar com excelente performance. Nos próximos dias vamos contar mais detalhes sobre o site.
O mais bacana ainda é que tudo o que ensinamos nos nossos cursos foram usados extensivamente na prática. Pegamos esse conhecimento prático e trouxemos para os nossos cursos de Frontend da Alura e presenciais da Caelum, onde você vai poder aprender todos esses conceitos e aplicar nos seus projetos.
E você, o que achou do site? E das nossas decisões arquiteturais? Vem aprender tudo isso com a gente.
