FrankenPHP: servidor de aplicações PHP moderno

 (frankenphp.dev)
4 pontos por GN⁺ 2024-05-31 | 1 comentários | Compartilhar no WhatsApp
  • Em fluxos de deploy que querem subir apps PHP sem um PHP-FPM separado, o FrankenPHP é um servidor de aplicações baseado em Go que incorpora o runtime oficial de PHP no Caddy, permitindo executar aplicações web PHP e scripts CLI com um único comando
  • Reúne como recursos padrão HTTP/1.1, HTTP/2, HTTP/3, certificados HTTPS automáticos, compressão Brotli/Zstandard/Gzip, logging estruturado e métricas Prometheus, reduzindo a necessidade de configuração do servidor
  • O modo Worker inicializa a aplicação uma vez e a mantém em memória, e afirma ter obtido resultado 3,5 vezes mais rápido que o FPM em benchmark próprio da aplicação API Platform
  • É compatível com PHP 8.2+, a maioria das extensões PHP e módulos do Caddy, e também oferece suporte nativo a extensões populares como OPcache e XDebug
  • Suporta imagem Docker, Kubernetes, plataformas de nuvem e distribuição como binário estático independente, o que pode simplificar a unidade de deploy de aplicações PHP

Forma de execução e fluxo básico de uso

  • O FrankenPHP se propõe a ser um servidor de aplicações PHP moderno escrito em Go, estruturando a instalação e a execução do servidor de aplicações PHP em torno de um único comando
  • Os exemplos de instalação são divididos por sistema operacional
  • A execução local cobre tanto servidor web quanto CLI
    • frankenphp php-server -r public/: serve o diretório public/
    • frankenphp php-cli script.php: executa um script PHP de linha de comando
  • A execução com Docker também usa a mesma imagem
    • A imagem dunglas/frankenphp serve o diretório public/
    • Na mesma imagem, também é possível executar scripts CLI como php script.php
  • A configuração é baseada em Caddy, e o exemplo ativa compressão dentro do bloco localhost e usa php_server para processar arquivos PHP e assets estáticos do diretório atual

Recursos do servidor e compatibilidade com PHP

  • Recursos do servidor web

    • Incorpora o runtime oficial de PHP ao Caddy
    • Suporta nativamente HTTP/1.1, HTTP/2 e HTTP/3
    • Automatiza a criação, renovação e revogação de certificados HTTPS via Let’s Encrypt ou ZeroSSL
    • Suporta por padrão compressão Brotli, Zstandard e Gzip
    • Inclui logging estruturado e suporte a Prometheus

  • Ambiente de execução PHP

    • Compatível com PHP 8.2+, a maioria das extensões PHP e todos os módulos do Caddy
    • Oferece suporte nativo a extensões PHP populares, incluindo OPcache e XDebug
    • Não requer PHP-FPM e usa sua própria SAPI criada para o servidor web em Go

Modo Worker e recursos voltados a desempenho

  • O modo Worker inicializa a aplicação uma vez e a mantém em memória, deixando-a pronta para processar requisições em poucos milissegundos
  • Há suporte nativo em Symfony, API Platform e Laravel
  • Usa os superglobais tradicionais do PHP sem PSR-7
  • Mesmo que a aplicação não seja compatível com o modo Worker, ela ainda pode ser servida normalmente
  • Oferece um watcher que reinicia automaticamente os workers quando o código muda
  • É apresentado como tendo desempenho 3,5 vezes superior ao FPM em benchmark próprio baseado em uma aplicação API Platform

Deploy e empacotamento

  • É possível fazer deploy de aplicações cloud-native com a imagem Docker
  • É compatível com Kubernetes e plataformas modernas de nuvem
  • Aplicações web PHP e ferramentas de linha de comando podem ser empacotadas como binários estáticos independentes
  • O projeto afirma que roda como um único serviço e um único binário, sem necessidade de serviços externos

Recursos adicionais da plataforma web

  • Suporta 103 Early Hints e apresenta o recurso, com base em um artigo da Cloudflare, como capaz de melhorar o tempo de carregamento de sites em 30%
  • Por meio do hub Mercure embutido, é possível enviar eventos de uma aplicação PHP para navegadores conectados, que podem receber o payload imediatamente como eventos JavaScript
  • Suporta deploy sem downtime com graceful reload

Leituras relacionadas

1 comentários

 
GN⁺ 2024-05-31
Opiniões no Hacker News
  • Faz quase 10 anos que não desenvolvo em PHP, mas esta landing page quase me fez colocar no ar nem que fosse um hello world
    O personagem de elefante Frankenstein é estranho, feio e fofo. O design, as cores, o texto e as animações também são bem caprichados. Para alguém que ficou afastado do desenvolvimento em PHP por um tempo, a proposta de valor fica clara, e parece bom para começar algo pequeno rapidamente
    • Há pouco mais de 10 anos migrei de PHP para Golang porque a distribuição em binário era boa demais
      Não quero subir 8 contêineres para isolar software ruim ou dependências enroladas. Não gosto da ideia de empacotar um “funciona na minha máquina” e jogar para o mundo em vez de entregar software instalável. Pela nostalgia, talvez eu mexa um pouco, mas não sei se ainda quero colocar algo assim em produção
    • É uma das melhores landing pages que já vi. Divertida e dá para entender de imediato
  • Trabalhei muito tempo com C# e hoje programo principalmente em PHP 8; é uma ótima linguagem para criar coisas rapidamente
    Em vez de seguir o caminho antigo do LAMP, que exigia uma configuração um tanto complexa do Apache, é para esse tipo de direção que a linguagem deveria ir
    • Tenho 18 anos de PHP, e com nginx + php-fpm 5 minutos são suficientes para configurar
      Também pretendo experimentar isto, mas nunca encontrei gargalo com nginx nem com Apache. Dá para subir ambos em alguns minutos, no máximo
    • Outra opção é o Nginx Unit: https://unit.nginx.org/
      Ele roda como um serviço único, como Apache + mod_php, lida com multiprocessamento de PHP e outras linguagens, arquivos estáticos e proxy reverso, e permite configurar tanto ele próprio quanto o PHP em uma única configuração em runtime via arquivo ou socket: https://unit.nginx.org/configuration/#php
      Um exemplo real de configuração é https://github.com/PrivateBin/docker-unit-alpine/blob/master..., e a imagem de contêiner resultante também pode ficar bem pequena: https://hub.docker.com/r/privatebin/unit-alpine
    • Quase não configuro PHP, mas, pelo que lembro de fazer uma vez a cada reinstalação do desktop, com apt-get terminava tudo de forma muito rápida e tranquila
      Não me lembro de ter feito muita coisa além de reiniciar o Apache
    • Fico me perguntando se a configuração do Apache é realmente tão ruim assim. Usando algo como PHP-FPM, parece bem aceitável: https://news.ycombinator.com/item?id=40256843
      É basicamente LoadModule proxy_fcgi_module "/usr/lib/apache2/modules/mod_proxy_fcgi.so" e SetHandler "proxy:fcgi://127.0.0.1:9000". Também há um exemplo de Nginx conceitualmente parecido com a forma de configurar o Apache, incluindo a instalação dos pacotes necessários: https://news.ycombinator.com/item?id=37443911
      Também existem imagens de contêiner pré-compiladas que dão um resultado parecido, mas, se quiser ver como funciona por dentro, dá para fazer manualmente. Com certeza é mais fácil do que configurar manualmente Tomcat ou GlassFish em servidores de aplicação Java antigos e, embora um único comando de execução seja melhor em qualquer ambiente, o LAMP não é tão ruim assim em comparação com outras stacks
    • Concordo. Se se consolidar uma cultura de depender de SQLite em vez de PostgreSQL/MySQL, toda a aplicação server-side poderá virar um binário independente simples
      Tendo um binário, também fica fácil empacotá-lo em um app Electron
  • Durante o desenvolvimento, uso bastante o servidor web embutido do PHP: php -S 0.0.0.0:8000 public/index.php
    Mas ele é single-thread e lento, então não serve para produção. O FrankenPHP parece promissor, mas o problema de limitação de cores/threads[2] também parece poder ser um problema em produção. Ainda assim, talvez eu aplique no projeto pure-todo[1] para ver se o mesmo problema aparece. A imagem Docker padrão parece muito boa
    1: https://github.com/sandreas/pure-todo
    2: https://github.com/dunglas/frankenphp/discussions/294
    • A documentação diz explicitamente que o servidor embutido do PHP não é para produção e é apenas para fins de desenvolvimento
      Veja o aviso no topo da página: https://www.php.net/manual/en/features.commandline.webserver...
      Nem sei se é justo usá-lo como comparação nesse contexto
    • Se você definir PHP_CLI_SERVER_WORKERS, dá para executá-lo com várias threads
    • Fico curioso se o motivo de não poder usá-lo em produção é apenas desempenho
      Para um site pequeno com poucos usuários, eu gostaria de saber o que se perde em relação a outros ambientes “prontos para produção”
    • Pelo que entendo, ele resolve esses problemas específicos de ser single-thread e lento, que o tornavam inadequado para produção. Imagino que também resolva outros problemas
  • Testei pessoalmente e foi realmente lento; também parecia não usar os cores direito. Passei um bom tempo lendo a documentação insuficiente, mas não consegui resolver
    Dizem que fica pronto para produção com poucos comandos e é 3,5 vezes mais rápido que FPM, mas, no meu ambiente, funcionou com cerca de 1% do desempenho do FPM. Também tentei o executável, mas o problema foi o mesmo; para um hello world, eu esperava pelo menos 200K rps
    • Sou o criador do FrankenPHP. Eu adoraria receber um exemplo reproduzível

Na maioria dos benchmarks, quando o modo worker está ativado, o FrankenPHP costuma ser muito mais rápido que o FPM, cerca de 3 vezes mais. Ainda assim há alguns casos de exceção, e estamos corrigindo isso junto com os mantenedores do PHP

  • Compartilhar essa experiência ajudaria a resolver isso: https://github.com/dunglas/frankenphp/discussions/294
    É uma situação bem estranha, porque o próprio Caddy tem desempenho muito bom quando usado com PHP
  • Tenho curiosidade para ver como ele vai se sair nos benchmarks da TechEmpower: https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
    No momento está lá embaixo como did not complete
  • Post relacionado: Show HN: FrankenPHP, um servidor de apps para PHP escrito em Go - https://news.ycombinator.com/item?id=33205282 - outubro de 2022, 83 comentários
  • https://github.com/dunglas/frankenphp/discussions/294
    Há problemas de desempenho. Tirando isso, é um projeto realmente promissor
    • Se eu conseguisse reproduzir, ficaria feliz em tirar 2 semanas de férias da empresa para corrigir. Ninguém explicou como reproduzir
  • Fiz benchmarks do WordPress no FrankenPHP e no Apache Mod-PHP, mas não vi evidências de que o FPHP vença
    Mas não me aprofundei, e os testes foram feitos dentro do Docker, não em uma configuração comum. O WordPress também estava praticamente na configuração padrão, sem temas pesados, então não eram condições realistas. Ainda assim quero refazer os testes e entender melhor
    • Ao contrário do Laravel e do Symfony, o WordPress ainda não oferece suporte ao modo worker do FrankenPHP, então não há muita vantagem de desempenho
      Ainda assim, com 103 Early Hints, dá para pré-carregar assets e reduzir a latência de carregamento da página em 30%. Mesmo assim, o FrankenPHP facilita ativar cache HTTP no WordPress e também simplifica a implantação. Há também um projeto específico para WordPress e FrankenPHP, que inclui um cache HTTP embutido personalizado para WordPress usando a biblioteca Go Souin: https://github.com/StephenMiracle/frankenwp
    • Talvez você use esse nome por familiaridade, mas, pelo padrão, no Apache deve-se usar proxy_fcgi
      Dá para economizar um pouco mais de memória do Apache e abrir espaço para lidar com mais requisições PHP
  • docker run -v $PWD:/app/public -p 443:443 \ dunglas/frankenphp
    Se quiser criar diretamente um contêiner Docker para servir o app, os comandos abaixo parecem suficientes para transformar um Debian novo no contêiner necessário: apt install -y apache2 libapache2-mod-php e a configuração de /etc/apache2/sites-enabled/000-default.conf
    Junto com amigos, mantenho um repositório que mostra o processo de ir do zero até uma aplicação web em execução em várias linguagens e frameworks populares: https://github.com/no-gravity/web_app_from_scratch
    • Comecei há um mês a trabalhar em uma empresa que usa mod_php, e é sofrido
      Toda vez que ativo o xdebug, preciso reiniciar o Apache depois da sessão de depuração. Desde ontem comecei a configurar o apache2 para usar php-fpm, e me pergunto se este FrankenPHP serviria para nós, ao menos no ambiente de desenvolvimento. Mas não encontrei na documentação como instalar extensões do PHP
    • Se eu não estiver enganado, isso não deve funcionar. O host virtual padrão 000-default.conf do Apache faz redirecionamento de 443 para 80?
  • Fico contente em ver isso na primeira página do HN
    O FPM e sua arquitetura shared-nothing foram fundamentais para o sucesso do PHP no passado, mas ao mesmo tempo sinto que também foram as correntes do PHP