Recentemente, fiz como projeto pessoal, um clone do chatgpt, o dgpt, foi um projeto bem divertido onde testei várias tecnologias emergentes e tive diversos tipos de satisfação usando essas tecnologias. Quero compartilhar alguns aprendizados e duvidas que tive.

IA

Após mexer um pouco com IA entendi o buzz ao redor, é muito divertido testar modelos, treina-los, ve-los delirando entre outros. O ferramental delas é bom, dependendo da linguagem de programação escolhida haverá mais ou menos recursos, por exemplo javascript e go tem a biblioteca langchain, em PHP, que foi a linguagem que escolhi existe um porte do langchain, que voce pode conferir aqui, porém ele ainda é muito embrionário, quando comecei a brincar com ia com go usei bastante o langchain em conjunto com llama.cpp, mas como não consegui fazer funcionar no php busquei alternativas e encontrei o ollama, um serviço web onde vários tipos de modelos podem ser adicionados, esse serviço é escrito em go e é muito util para testar modelos, como no caso do meu projeto.

Ao usa-lo vi a grande barreira para usar IA de modo "caseiro", elas necessitam de muitos recursos da maquina, os modelos tem cada vez mais parâmetros, logo são muito maiores, necessitam de bastante processamento e memória. Existem modelos menores, mas eles tendem a ser menos eficazes e mesmo modelos pequenos exigem bastante da maquina.

HTMX

Num primeiro momento pensei em usar uma lib ou framework js como solid ou svelte ao outro para aprender, mas resolvi experimentar o "hyper" do htmx. O htmx é uma lib muito competente, pequena, performática, com conceitos muito interessantes, com ele fiz algumas tarefas que exigiram algumas linhas de JS em uma linha com alguns atributos em tags html, parecido em como fazia quando estava aprendendo e tudo que sabia usar era o GRANDIOSO jqeury.

Contudo no decorrer da experiencia percebi alguns engasgos que nao teria usando um lib ou framework js, como na parte do chat onde precisava adicionar vários dinamicamente alguns campos e me vi lutando contra o htmx ao invés de ser ajudado, coisa que quando lembro de ter aprendido svelte, react ou outro framework não lembro de ter acontecido, claro que com mais estudo e pratica esses pontos podem ser mitigados e eu perceba que o htmx é a panacea para o frontend, porem minha impressão atual é: ele é bom para coisas que exigem pouca interação, mas da feita que sua pagina precisa de mais interações ele começa a mostrar sua limitações.

Mercure

Quando fiz o projeto queria usar websockets para quando a mensagem fosse escrita, ele mandar a resposta de acordo com o que fosse recebendo ao invés de esperar a resposta ficar pronta e mandar tudo, ate porque por causa da limitação da minha maquina o processo terminava em timeout. Não queria usar nenhum serviço externo, então busquei alternativas em php, não achei nenhuma boa para rodar localmente, neste projeto usei o frankenphp e em sua documentação comenta que ele ja vem com um servidor Mercure embutido então fui ver do que se tratava.

Mercure é um protocolo pensando em comunicação em tempo real, de alto nível, funciona por padrão nos browsers modernos. É fácil e simples de usar, tem uma performance incrível, com certeza é algo que utilizarei sempre que uma solução exija comunicação em tempo real. A única ressalva e que estudarei melhor como levantar um servidor mercure em um ambiente onde ele não é embutido pro padrão.

Frankenphp

Em novembro foi lançado para produção um novo runtime php, o frankenphp, ele vem com um conceito muito legal que é o worker mode, onde após a inicialização o projeto php todo fica em memória, fazendo com que as requisições subsequentes nao tenham o overhead de carregar todas as libs e subir todos os processos, como aplicativos usando o php-fpm fazem, como 25 a 50% do response time do php é composto apenas do boot da aplicação isso de cara ja faz o php ficar bem mais rápido. Neste video do Dias de dev a um benchmark que mostra bem o potencial do frankenphp em comparação com libs estabelecidas como o Swoole, no video fica claro que o benchmark não foi feito para comprar ambas, porem os números são bastante reveladores.

Integrar o slim framework com o frankenphp foi simples, durante todo o desenvolvimento não usei o woker mode, pois quando em memória a aplicação so é alterada quando ela é terminada e levantada novamente. Mesmo sem usar o worker mode a aplicação ja é bastante responsivo por usar o caddy server, em worker mode ela também fica mais rápida, porem como a minha aplicação não exige muito processamento, por delegar o processamento para o olham, não da para notar aumentos dramáticos de performance, mas ha um perceptível aumento de performance.

O PHP é sempre ótimo de trabalhar, é uma linguagem que sou apaixonado e ver seu progresso ano após ano é fantástico.

Conclusão

Estudar novas tecnologias sempre é bom, mas as vezes pode ser algo tao distante da realidade do trabalho ou do que as vagas pedem que desanima as pessoas de fazerem. Tendo essa experiência aprimorei algumas habilidades e descobri coisas que podem se aplicar em projetos atuais como o ollama e o mercure. Recomendo a todos que tenham seus projetos de duas ou tres semanas para testar tecnologias novas e aprender novos conceitos.