A entrevista com um dos developers do Twitter que foi alvo de várias discussões, críticas de todos os lados acabou mais focada na declaração sobre a falta de uma maneira nativa do Rails trabalhar com mais de um servidor de base de dados do que em outro ponto que eu até acho que é mais importante e pouco divulgado do framework: quanto mais se otimizada a parte de ActiveRecord do Rails mais distante o framework fica daquilo que foi vendido para o usuário em tutoriais de web e livros.
O que falta mesmo é algum tipo de documentação, um livro, que aborde esse Rails “de alto impacto” praticado por sites como o 43things e Twitter e não só somente o Rails “ginastica aquática” dos livros que estão no mercado agora.
Model.find_by_id é lindo, mas não existe numa aplicação de tráfego alto. É essa parte bonita que fez um grande número de developers se apaixonar pelo framework de primeira e que vai sendo substituída pelos SQLs feios do find_by_sql (que você achava que estava alí só para usar de vez enquando) a medida que se vai tentando se livrar dos gargalos de uma aplicação.
Eu concordo com o DHH quando ele reclama que o Twitter poderia ter solucionado o problema da falta de suporte a múltiplas base de dados e ter distribuído a solução assim como os caras da 43Things fizeram com o plugin cached-model, de suporte ao Memcached. Mas acho importante que se diga que, saído da caixa, o Rails não escalona bem, e, mesmo havendo receitas já comprovadas de escalonamento, o ActiveRecord vai comprometer um pouco seu aspecto ágil para conseguir entregar os pageviews que a sua aplicação precisa. Não é igual ao exemplo do livro.
O Rails vem com alguns métodos de caching embutidos, o que mostra que a habilidade de rodar aplicações de maior porte é algo que a equipe de desenvolvimento leva em consideração. Tenho certeza que a próxima leva de livros, bem como a próxima versão do Rails, vai focar basicamente nisso.