Com CakePHP na Prática

nicke.dev
nicke.dev
Jul 27, 2017 · 5 min read

O PHP por muito tempo foi um hobby de alguns momentos para algumas pequenas finalidades. A um tempo atrás virou uma das minhas principais atividades. Comecei com PHP num momento em que as pessoas (do meu pequeno ecossistema) tinham bastante preconceito com os frameworks, alguns evangelizavam que o o código bom deveria ser “na unha” (aposto que você já deve ter ouvido isso), e todos tinham orgulho de mostrar a sua “salada de códigos” como um produto refinado, onde muitas vezes existia o HTML misturado com milhões de tags do PHP embebido de muito SQL.

Acho que isso acaba sendo o normal de muito iniciante não só nessa linguagem em particular, o fato de abstrair de forma correta e codificar de forma limpa é um processo contínuo que exige bastante esforço e cobrança do próprio desenvolvedor.

Quando começamos um trabalho de médio porte na empresa em que trabalhava, descobri que precisaria encontrar alguma coisa que fosse prática e de curva de aprendizagem rápida, mas que houvesse também uma certa quantidade de respaldo e confiabilidade. Entre pesquisas descobri o CakePHP, na época acho que na versão 2.0 ou 2.1, parecia ser algo bom, com uma relativa quantidade de bugfixes, um ecossistema de devs com um bom fluxo de atividades e interações, então comecei o planejamento e sequencialmente o desenvolvimento.

Inicialmente foi amor a primeira vista, a ORM fácil de se trabalhar, o processo de convenções em vez de configuração e tudo mais que o pacote tinha direito. Começamos a implementar nossa solução e… quantas dores de cabeça. O framework nos ajudou em muitos momentos, mas tivemos alguns entraves que para o negócio funcionar como desejávamos precisou de muitas customizações, por exemplo:

  • ACL, fundamental para o nosso modelo multi-usuário, utilizamos um plugin chamado ArrayAcl, customizamos junto com o processo de automação do plugin do próprio Mark Story (markstory/acl_extras) pra conseguir resgatar a autorização via banco de dados e ainda conseguir uma sub-acl porque no sistema cada proprietário poderia ter múltiplas empresas, e cada empresa gerenciaria individualmente o acesso de seus funcionários.
  • Multitenant, nossa, fazer isso com o cake 2.x foi muito difícil, devido ao grau de individualidade dos registros e consequentemente a velocidade de pesquisa no mysql chegamos a conclusão que a longo prazo a carga seria melhor dividida se cada cliente tivesse seu próprio banco de dados, e como?! Muita luta nessa hora, meu amigo o Rafael fez uma implementação que modificava (e sobrescrevia) alguns métodos que trabalhavam com os models pra conseguirmos alternar os bancos em tempo de execução.
  • Trees, quem nunca teve que mexer com elas?! Meu amigo, a sua vez chegará, seja numa árvore de diretórios ou um menu editável. No nosso caso foi o pagamento de comissões para os vendedores de acordo com as indicação, o sistema percorria a arvore e pagava as porcentagens ao vendedor de acordo com o nível de indicação.
  • RealTime, os clientes queria acompanhar suas cifras ($) em tempo real, imagine, devido ao nosso tempo de entrega implementamos ajax em um loop (má prática, diga-se de passagem, não faça isso em casa!).
  • Contain e SubQuerys, devido aos relacionamentos das tabelas, utilizamos muito o ContainableBehavior e subquery para muitos dados, e adivinhe os dados quebraram em relacionamentos distantes, foi preciso mais modificações para deixar os dados retornados confiáveis.
  • Multi Idiomas, o modelo do Cake gera arquivos externos para tradução, você (para facilitar) teria que usar uma ferramenta externa para criar as traduções.
  • Consultas excessivas, muitas querys geradas nos relacionamentos grandes, a carga estava consumindo muitos recursos do nosso servidor.

Esses foram alguns dos pontos críticos com o framework, tivemos muitas sobrescritas de métodos do core para abraçar nossas solicitações. O projeto base era bem pequeno no momento da análise de requisitos, e como sempre foi crescendo exponencialmente em funcionalidades com muito pouco prazo pra entrega. O Cake foi uma grande escola, sobre coisas que conseguimos fazer dar certo, coisas que gostaríamos que pudesse ter dado certo e de como um framework opera ou deveria operar.

Pra mim foi a primeira experiência com um framework em PHP de forma funcional (fora os tutorias de blog que todos fazemos), nesse meio tempo, sempre terminávamos com pessoas comentando seus problemas (semelhantes) no StackOverflow, o cakephp 3.x ainda estava em desenvolvimento, e se nós achávamos que estava difícil com o 2.x imagina o pessoal da versão 1.x que tinha sistemas em ambiente de produção.

O Cake 3.x.x corrigiu vários gargalos dos problemas que encontramos, foi uma ótima restruturação, infelizmente não compensava portar o sistema devido ao grau de customização. Por ser a primeira experiência, também tenho ciência de ter algum código ruim rodando no projeto, a falta de tato com ferramentas novas unida da escarces de tempo só pioram o produto final. Nosso projeto foi inflando de funcionalidades, quase não havia tempo pra revisar, e no fim das contas o deploy foi bem difícil.

A experiência foi muito válida, me permitiu aprender bastante, tanto com o modelo de negócio quanto com a qualidade do código, amadureceu bastante meu senso crítico, infelizmente ficamos com um produto legado.

Atualmente estou utilizando o Laravel para os projetos, não acho que o Cake seja ruim, mas depois da experiência com a versão 2.x.x comecei a trabalhar com o produto do Taylor Otwell. A sua comunidade é muito boa, temos bastante publicações (mesmo não oficiais), o laracasts ajuda bastante na curva de aprendizagem. Na minha experiência, com o Laravel eu senti muito mais controle sobre a aplicação, abriu mais o leque de possibilidades, mesmo que se codifique ou configure mais em alguns momentos eu achei que o processo ficou mais enxuto.

Não recomendaria jamais as versões do CakePHP antes do 3.x.x, devido aos meus problemas, as coisas que se repetiam em cada cenário das aplicações que fizemos (sim, utilizei o cake em outros projetos paralelos) me gerou a necessidade de mudança.

Desenvolver é sempre um desafio, saber escolher a ferramenta que melhor se encaixa em cada ocasião é fator decisivo no ganho de tempo, na qualidade, na experiência. Acho que hoje o melhor é errar rápido afim de aprender e buscar sempre melhorar uma vez que não há uma solução ideal. CakePHP é uma boa ferramenta, infelizmente algumas coisas não se encaixaram bem as nossas necessidades e ao nosso cenário, existem pessoas que trabalham com ele e são “cases” de sucesso, meu objetivo não foi fazer uma crítica, mas expor uma experiência real e pessoal de trabalho.

nicke.dev

Written by

nicke.dev

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade