Até onde uma biblioteca deve crescer antes de perder seu propósito?

Só que existem muitas funcionalidades que poderiam ser interessantes

todas essas ao meu ver fogem do escopo original. acredito que se você fosse implementar qualquer uma deveria fazer bibliotecas adicionais e modulares, ex:

http-streaming, http-cache, http-mqtt, ...

assim quem quiser usar só o módulo base consegue, e quem precisar de adicionais tem o poder de customizar.

A questão é quanto tu quer se dedicar a manter tudo isso

Desde que comecei a usar Rust algum tempo atrás, notei um padrão em praticamente todos os projetos sérios: A arquitetura é levado muito a sério.

Projetos como Tokio, Hyper, Mio, Serde, dentre outros levam o design da crate (equivalente a uma "lib) muito a sério. Os mantedores não hesitam em fechar uma issue que pede uma feature fora do escopo. Se a demanda tá alta, criam uma crate específica para isso, que é o caso do Reqwest.

Reqwest é um client http em Rust pronto para uso. Rust é primordialmente uma linguagem de baixo nível, mas com Reqwest você consegue criar um servidor http (ou client) em minutos. Porém existe o Hyper que é uma biblioteca "low-level". O intuito do Hyper é prover ferramentas para você montar outras ferramentas HTTP. Muita gente pediu, ou tentou adicionar abstrações parecidas com o Reqwest, que não foram aceitas, preservado o propósito do projeto.

Detalhe: Reqwest e Hyper são dos mesmos mantedores.

O escopo do projeto é definido, e não foge disto. Fugiu disto? Melhor criar uma ferramenta nova específica para isso. Menos complexidade em código, menos gambiarra (glue) entre camadas, menos responsabilidades, menor build, menos latência, menos gerênciamento de memória, menos bugs, menos dor de cabeça, CI mais rápido... São tantos benfícios.

Em toda a minha vida a parte mais difícil nunca foi codificar, mas entender e criar arquiteturas escalavéis. Por isso gostaria de reforçar que, defina o escopo, para não virar "bagunça".

Uma vez que implementou uma feature que não faz sentido para o projeto, já era. Não se pode simplesmente remover isto. Pessoas criaram ferramentas usando versão "x" que contém esta versão. Remover isso é uma breaking change que exige uma manutenção absurda, fazendo usuários migrar para algo mais estavél e previsível. Um único commit errado já pode complicar a vida de milhares de pessoas, imagina uma feature inteira?

É muito importante considerar esses cenários, como escopo, escalabilidade, se faz sentido, e etc...

Acho que o ponto principal é exatamente esse: manter o core simples e deixar funcionalidades mais específicas como módulos separados. Assim a biblioteca continua tendo um propósito claro sem limitar quem quiser expandir

Meus 2 cents,

Parabens pela iniciativa !

Sigo com os relatores @Pilati e @Programmer404: principio KISS na veia e features complementares como projetos separados, seja para uma manutencao mais simples, seja para manter o tamanho sob controle (ainda mais em um ambiente compacto como esp32).

Repositorio ja sido devidamente starreado e forkeado anteriormente e obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

Sempre depende do seu objetivo, tem gente que começa a escrever framework e acaba construindo um runtime de backend web e serviços.

Esse dilema é o clássico ponto de virada de qualquer projeto open-source que começa a ter tração. Parabéns pelo alcance da biblioteca!
No caso de sistemas embarcados como o ESP32, onde memória RAM e estabilidade de sockets são recursos escassos, o maior valor da sua biblioteca é justamente a promessa inicial: ser leve, simples e previsível.
Para não perder o propósito, uma boa regra arquitetural é separar o que é "evolução de transporte HTTP" do que são "outros protocolos/camadas":
1.O que pertence ao core: streaming de payload, timeouts bem tratados, suporte a chunked transfer e upload/download eficiente. Isso continua sendo estritamente HTTP.
2.O que NÃO pertence ao core: MQTT e WebSocket são protocolos de transporte completamente diferentes. Colocar MQTT dentro de um cliente HTTP quebra o Princípio da Responsabilidade Única (SRP) e incha o binário para quem só queria fazer um POST simples.
3.Camadas superiores: GraphQL e MCP rodam sobre HTTP. Em vez de embutir essas regras na biblioteca, o ideal é expor uma interface limpa para que outras bibliotecas possam usar o seu cliente como motor de transporte.
A melhor estratégia para manter o projeto respeitado a longo prazo é a Filosofia Unix: mantenha o core minimalista, afiado e focado em ser o melhor cliente HTTP para ESP32. Se quiser suportar outros protocolos no futuro, crie bibliotecas irmãs e modulares.
Quem escolhe uma biblioteca para microcontrolador prefere 10x uma ferramenta pequena que nunca quebra do que um canivete suíço pesado.