Por que Laravel?

Observação: este é um post técnico.

Depois de lançar o Monica no Hacker News, recebi muitas perguntas sobre por que escolhi escrever a ferramenta em PHP e, em particular, com Laravel. Fiquei surpreso com tantas perguntas sobre o assunto, porque considero que a linguagem não importa: só conta o que você faz com ela.

Neste post vou contar por que escolhi PHP e Laravel e quais dificuldades precisei superar para construir a primeira versão do produto. O texto não pretende começar uma guerra entre linguagens.

O PHP tem uma história interessante. Muitos ótimos desenvolvedores web, que provavelmente não usam mais PHP, aprenderam com ele as bases da programação. Era simples de usar e de começar e, embora não fosse uma linguagem elegante, abriu caminho para carreiras no desenvolvimento web. Com o tempo, o PHP passou a ser menos amado, a ponto de ser quase vergonhoso usá-lo ou até dizer em um meetup que sua empresa o utilizava. Outras linguagens, sem dúvida mais elegantes, ganharam muita popularidade (Python, Ruby) graças a frameworks maravilhosos construídos sobre elas. Ao mesmo tempo, surgiram novos frameworks PHP. O Symfony, por exemplo. Mas o Symfony ainda era difícil de aprender e de usar. E então o PHP morreu. Ou pelo menos era o que diziam, ignorando aparentemente que muita gente do mundo dos negócios continuava usando e gostando dele. Depois veio o PHP 5.5, seguido do PHP 7, e apareceu um framework com um nome estranho: Laravel. E a mentalidade das pessoas mudou completamente. O PHP ainda não é tão elegante quanto outras linguagens populares, mas as coisas melhoraram muito. E ele também ficou rápido.

Mesmo assim, o PHP continua sendo a linguagem que as pessoas adoram odiar, especialmente no Hacker News. Dizem que o PHP não escala. Provavelmente é por isso que o Facebook e o Mailchimp, entre outros grandes nomes, usam PHP hoje, em grande escala.

Com esse contexto em mente, por que escolhi PHP e Laravel?

• O PHP é simples de aprender e simples de usar.
• Existem muitos desenvolvedores PHP e, se as pessoas quiserem trabalhar comigo no projeto, o grupo potencial de desenvolvedores PHP é maior, pelo menos onde eu moro, do que o de Ruby ou Python. Além disso, há muita gente no GitHub usando PHP e, se eu quisesse que este projeto de código aberto ganhasse tração, tinha que escrevê-lo em uma linguagem em que pessoas de diferentes níveis pudessem contribuir com facilidade.
• O mais importante ao escolher uma pilha tecnológica para um projeto novo é o quanto será fácil mantê-lo no longo prazo. O PHP é simples. É fácil de depurar (embora pudesse ser melhor) e fácil de escalar (embora isso não seja de forma alguma minha preocupação agora).
• O Laravel é de longe o melhor framework PHP que já usei. Ele torna simples fazer coisas complexas. Fica claro que o framework foi criado para iniciar novas aplicações web bem rápido, e é um verdadeiro prazer usá-lo. Mas o grande diferencial do Laravel é a qualidade da documentação, comparada à de outros frameworks PHP e até de muitos frameworks em outras linguagens. Tudo é extremamente bem documentado. Não consigo enfatizar o suficiente como uma boa documentação é importante (o que me lembra que eu deveria documentar ainda mais o Monica).
• Há uma enorme comunidade em torno do PHP e do Laravel em particular: Laracasts, Forge, Envoyer e uma comunidade forte no Slack, para citar algumas. Se você precisar de ajuda, há muita gente pronta para dar uma mão.

Quais desafios enfrentei durante o desenvolvimento deste projeto?

No geral não tive tantos desafios ao desenvolver a versão atual do Monica. Não é uma aplicação complexa e não tenho problemas de escala, já que a base de usuários ainda é pequena (cerca de 7800 usuários no total e 4300 ativos). Mas há detalhes de implementação que fiz errado, não por má prática, mas porque minhas habilidades técnicas não eram suficientes para resolver esses problemas no curto prazo. Espero que listar esses erros ajude outras pessoas a não cometê-los, ou que gente gentil me escreva contando como eu poderia tê-los corrigido.

• Em versões anteriores, eu usava muitos eventos e listeners. O conceito é ótimo, mas tive muitos problemas para testar unitariamente as classes base por causa deles. Além disso, quanto mais os usava, mais mágica acontecia nos bastidores. Achei que quem entrasse no código teria dificuldade para entender por que certas coisas aconteciam quando um objeto era criado, por exemplo. Na minha cabeça, eventos e listeners tornavam a aplicação mais difícil de entender, então decidi remover todos (bem, 99% deles, ainda há dois listeners dos quais preciso me livrar).
• No começo, o banco de dados era inteiramente criptografado. Por razões que ainda não entendi, de vez em quando havia bugs no processo de descriptografia, resultando em dados que eu não conseguia recuperar. Como não queria lidar com esse problema naquele momento, decidi remover a criptografia. Além disso, dados criptografados tornavam impossível qualquer ordenação ou busca nas consultas, o que teria sido problemático no longo prazo. Tenho certeza de que há soluções para esses dois problemas, mas eu queria focar em criar novas funcionalidades em vez de resolver esse único ponto.
• Não escrevi testes unitários antes de lançar a aplicação. Isso me custou caro. Não acho que devamos buscar 100% de cobertura, mas ao menos ter algum tipo de teste para as funcionalidades principais do site. Caso contrário, você acaba com uma tonelada de bugs em que não havia pensado e, enquanto tenta corrigi-los, outras partes da aplicação são afetadas pela correção. Isso vira um pesadelo rapidinho. O Laravel torna os testes unitários muito fáceis: eu deveria ter levado isso mais a sério. A partir da próxima versão, nenhum pull request será integrado sem testes unitários e talvez até testes funcionais.

Conclusão

Estas são algumas razões pelas quais escolhi o Laravel. Como disse no começo do post, seu projeto não é sobre a linguagem. A menos que o objetivo do projeto seja aprender uma linguagem nova, você não deveria passar semanas escolhendo linguagem ou framework. Fique com o que você conhece e faça alguma coisa. Seus usuários não vão se importar se o código é feio ou se você escolheu Python em vez de Ruby.