PHP: Quando é uma boa ideia?

Antes que você responda "nunca" para a pergunta no título, me dê uma chance de tentar te dar argumentos 😉

Particularmente eu sou o tipo de pessoa que gosta de ver prós e contras ao tomar uma decisão, e como um desenvolvedor, já passei por aquela pergunta clássica: "qual linguagem/stack usar para esse projeto?".

Nesse post vou deixar a minha visão de prós e contras de se usar PHP em projetos de portes diferentes, dando mais foco ao Laravel, um dos framework mais populares do PHP.

Prós

Curva de aprendizado e comunidade

Caso tenha interesse, você pode dar uma lida na história do PHP aqui, o motivo da sua criação é bem legal 😁.

O PHP é uma linguagem bem difundida na internet, na pesquisa do stackoverflow, apresenta bons números que representam isso:

Cerca de 21% dos profissionais, de um total de 53.421 respostas, trabalham com PHP: stackoverflow1

Enquanto cerca de 19% de um total de 6.239 respostas estão aprendendo PHP: stackoverflow1 Fonte: Pesquisa 2022 stackoverflow

Mesmo que esses números não necessariamente indicam uso de Laravel, apenas PHP, eles nos mostram que a comunidade atual é notória e não deve sofrer perdas para outras linguagens/tecnologias no período a curto/médio prazo.

A discrepância do Typescript é bem grande, será que veremos uma decadência da linguagem nos próximos anos 👀?

Também podemos usar estrelas do github como um parâmetro de popularidade. Repare que eu usei a palavra "popularidade", isso significa que as pessoas conhecem, não necessariamente gostam, ou se quer usam no dia a dia.

stackoverflow1 Fonte: Star-history

Podemos observar que dentre os frameworks listados, Laravel é o terceiro mais antigo e o mais popular, ele apresenta um bom cresencimento por mais que dê para notar uma leve curva decrescente (também notável no express), o que indica pode indicar uma futura perca de ritmo de crescimento da popularidade (detalhe: isso é apenas especulação pessoal minha).

Laravel

Laravel é o framework mais popular do PHP, a ideia que ele tráz é de ser um framework robusto que consiga resolver todos os seus problemas sem depender de outras bibliotecas.

O Laravel trás algumas "pré-implementações" que agilizam no desenvolvimento, aumentando a produtividade, por exemplo, salvar assets em um storage, O Laravel já tráz um facade que apenas ao mudar uma variável de ambiente de local para S3, você já terá configurado a sua persistência para salvar dados em algum bucket na AWS ao invés de salvar na sua própria máquina. Se quiser ver uns exemplos: Filesystem - Documentação Laravel

Essa ideia de "pré-implementações" se seguem para outros cenários como, email, sms, fila, cache e entre outros.

Hospedagem

Atualmente existem muitas hospedagens de wordpress que são muito acessíveis, apartir de R$ 7,00 por mês é possível hospedar sua aplicação (valor do hostinger, 12/12/2022).

Essas hospedagens normalmente possui alguns facilitadores para configurar o wordpress nelas, só que na verdade elas hospedam PHP, ou seja, qualquer código que seja em PHP poderá ser hospedado lá. Se tratando do Laravel, normalmente a configuração é bem tranquila, normalmente basta fazer:

  1. Configurar o arquivo .htaccess dentro da pasta public
<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews -Indexes
    </IfModule>

    RewriteEngine On

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.+)/$
    RewriteRule ^ %1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>
  1. É necessário enviar para a hospedagem os arquivos estáticos gerados pelo webpack, o que pode variar dependendo do seu processo de build/deploy.

Claro, que existem outros passos de configuração, mas acredito que sejam configurações "mais óbvias". Mas apenas com isso, sua aplicação, seja api ou web, já estará disponível.

Produtividade

PHP é uma linguagem interpretada, isso significa que durante o processo de desenvolvimento, você não precisa recompilar seu código para testar as coisas, se somar isso com um intellisense descente e um debbuger, você vai voar =)

Mesmo sendo uma lingaguem interpretada os intellisenses até que funcionam bem. Normalmente eles fazem um processo de indexar o seu código para te dar um feeling de uma lingaguem compilada. Assim fica muito mais fácil navegar pelo código, descobrir quais são os parâmetros dos métodos, etc.

Claro, que isso também implica em um lado negativo que vou deixar para a próxima seção.

Contras

Os principais contras do PHP são relacionados a performance. Infelizmente eu tenho dificuldades para encontrar bons benchmarks de PHP/Laravel, mas vou deixar esse aqui e esse outro para caso queiram se aprofundar na leitura.

Linguagem interpretada

Como dito anteriomente, PHP é uma lingaguem interpretada. Isso significa que o clássico processo de compilação não é necessário. Por natureza, isso indica uma possível perda de performance, normalmente relacionada a latência (vou falar disso mais a frente).

Além disso, em projetos maiores, pode acontecer de alguém renomear alguma variavél/propriedade e quando for testar vai ter a falsa sensasão que deu tudo certo, até subir a versão para produção e descobrir que aquela variavél era usada em outros lugares, sim, eu já vi isso acontecer. Esse cenário seria facilmente evitado em uma lingaguem compilada. Por mais que se ganhe em produtividade, se acaba perdendo em segurança.

Claro que também existe o fator de que os compiladores atualmente são muito inteligentes, alguns deles tem a capacidade de reescrever seu código o deixando melhor, claro que o PHP também faz esse processo, mas quando esse processo acontece antes do código ser executado, me parece um processo "mais limpo".

Latência

A latência das suas requisições vão depender de quanto esforço você quer colocar pra diminuir elas. Por padrão, qualquer rota simples, como um login, vai ter uma média de uns 250ms, entretanto, outras rotas mais complexas (que faz acesso a banco e sistemas de terceiros) não vão fugir muito disso.

Parte desse problema é causado pela soma de dois fatores: a necessidade de "compilar sob-demanda" junto com a forma que o PHP lida com requisições. Cada nova requisição é tratada como uma thread, ou seja, com várias requisições seu servidor vai abrir várias threads concorrentes, que vão competir por tempo de processamento, o que é um alerta para aplicações que tendem a crescer muito.

Outro ponto que não ajuda o PHP a ter uma latência boa é a falta do amado e odiado async/await. Em outras linguagens esse recurso evita entradas e saídas bloqueantes (Blocking I/O), se você for ler um arquivo ou fazer uma consulta no banco, sua aplicação não precisará ficar esperando pela resposta, apenas quando necessário. Ou seja, a ausência desse recurso no PHP acaba somando no tempo de resposta da requisição.

Claro que existem alternativas para resolver esse problema, como o Swoole, mas não ter essa solução nativa na linguagem é triste :'(. Também não podemos descartar que com o tempo a linguagem evolui, tanto em usabilidade quanto em performance.

Aqui tem um artigo bem interessante sobre esse ponto de latência e threads no PHP: https://sergeyzhuk.me/2021/03/03/myths-about-asynchronous-php/

TL;DR

Em projetos pequenos, de baixo custo e que provavelmente não vão escalar muito (ou rápido), como algumas POCs e MVPs, PHP parece ser uma boa escolha. O próprio Laravel é um framework com bastante ferramentas úteis que agilizam bastante o desenvolvimento, além disso possui uma ampla comunidade e sintaxe relativamente comum. Achar uma hospedagem gratuita ou de baixo custo, também é bem fácil já que as hospedagens de wordpress normalmente também servem para Laravel já que ambos são PHP.

Para projetos de médio porte já é uma alternativa mais delicada. É necessário avaliar o futuro desse projeto, o que terá, qual será seu uso, se terá que ter uma boa performance/latência. Nesse caso, acredito que só vale a pena escolher o PHP caso seja a principal stack da equipe e o prazo esteja apertado.

Já em projetos grandes é mais fácil olhar os pontos contras e logo dizer que PHP não será uma boa escolha. Claro que sempre existem as exceções e comentários do tipo: "ah mas empresa X usa PHP e é enorme", mas será que se eles tivessem opção de mudar o passado escolheriam PHP novamente? Claro que quando uma arquitetura e implementação é bem feita diminui os problemas de performance do PHP, mas se você tem a opção de fazer a mesma coisa com a mesma qualidade só que com menos esforço, não faria?

Muito interessante seu post, porém tem alguns pontos que eu discordo e vou-lhe mostrar o porque.

  1. PHP não é interpretado ocasiona perca de performance Isso até pode ser verdade, porém há formas de contornar isso de uma maneira bem legal. De uma maneira geral, sabendo configurar o ambiente você não terá problemas e isso deve ocorrer somente em ambiente de dev/qa. O PHP possui o opcache, que são caches de bytecode que 'pula' a etada de interpretação a cada request, dando um ganho de memória GIGANTESCO. A maior parte da latência é justamente nesse momento de interpretação do script, então com o opcache já eliminamos um bom tempo de resposta (:. Com o PHP 8 ainda tivemos a implementação do JIT que é um opcache 'com bomba', que ajuda ainda mais a aplicação ganhar performance. Você terá um ganho gigantesco de performance e provavelmente isso não será problema. Moral: Se você está com problema de performance PROVAVELMENTE (eu disse provavelmente) o problema não é a linguagem, mas sim a configuração do ambiente ou código.

Eu palestrei sobre isso recentemente em duas faculdades, caso queira dar uma olhada, aqui estão os slides: https://speakerdeck.com/renandelmonico/tunando-seu-php-em-producao-com-cache-de-bytecode.

  1. Falta de async/await Claro, isso é um 'problema', porém pode ser contornado em qualquer aplicação. Trabalho com CQRS e os comandos são sempre 'Fire and forget', ou seja, eu envio uma requisição para a aplicação e não fico esperando executar determinada ação para ter uma resposta, possuo um middleware que já me devolve uma resposta enquanto o PHP fica processando 'por trás dos panos'. Dê uma olhada nas funções ignore_user_abort(), ob_start(), ob_end_flush(), ob_flush() e flush().

  2. PHP para projetos médios/grandes Na empresa que trabalho usamos PHP para projetos grandes e processamento de um bom número de dados e não temos problemas com performance. Com as ferramentas certas (profiling da aplicação) conseguimos identificar facilmente onde o código está lento e otimizar e normalmente é problema de lógica. Então sim, eu usaria PHP para projetos maiores, PORÉM depente do que o projeto se propõe. Com certeza devemos considerar as demais linguagens antes de tomar uma decisão.

Gostei muito do seu comentário =) Concordo que com o opcache ajuda bastante a performance e ele é bem tranquilo de configurar. Sobre essa questão do async/await, acaba caindo na ponto de alternativas como comentei no texto, conheco o Swoole. Ele possui essas chamadas "por de baixo do capo" que você comentou. No geral, ainda me parece que é um esforço adicional (e talvez desnecessário) quando você tem outras opções que já resolvem isso nativamente, o que acaba (na minha opinião) derrubando a possibilidade de criar novos projetos grandes em PHP. Claro que quando você já tem sistemas escritos é uma outra história..
Sim, é um esforço adicional que precisamos fazer quando queremos algo assíncrono. Em alguns casos vai resolver, mas também acho que o PHP precisa de algo nativo para criarmos funções nativas assíncronas. Historicamente o PHP demora um pouco para adotar novas ideias. A linguagem "espera" algo ser "validado" por outra para depois implementar nela, o que acaba ocasionando essa "demora". Acredito que em versões futuras o async/await venha :D