3
pedrofnseca
2 min de leitura ·

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

Há algum tempo venho desenvolvendo uma biblioteca open source para ESP32 chamada ESP32-HTTP-Client.

Ela começou como um projeto pessoal para criar um cliente HTTP simples, leve e com baixo consumo de memória. Com o tempo, começaram a surgir issues, sugestões e pessoas utilizando o projeto.

Um dos momentos que mais me surpreendeu foi quando um post que fiz sobre a biblioteca no LinkedIn passou de 1.300 curtidas, recebi issues de alguns paises e feedbacks.

Para mim, isso foi muito legal, principalmente porque o projeto começou como uma forma de aprender.

E ele acabou se tornando algo ainda mais importante: uma maneira de sair um pouco da rotina de apenas entregar funcionalidades no trabalho e voltar a construir coisas porque quero entender como elas funcionam

Trabalhar com ESP32 também me força a pensar em coisas que muitas vezes ficam escondidas em aplicações tradicionais: memória, conexões, timeouts, headers, sockets e limitações de hardware

Mas agora eu estou em um dilema

A biblioteca tem um propósito bem definido: ser um cliente HTTP para ESP32.

Só que existem muitas funcionalidades que poderiam ser interessantes:

  • streaming;
  • cache HTTP;
  • upload/download;
  • Graphql;
  • Mqtt;
  • MCP;
  • WebSocket;
  • entre várias outras.

E aí comecei a me perguntar:

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

Não quero simplesmente adicionar funcionalidades porque parecem legais. Quero continuar evoluindo a biblioteca sem transformá-la em um projeto completamente diferente.

Então queria a opinião de vocês

E não precisa entender de ESP32, C++ ou baixo nível.

Na verdade, quero que vocês viajem nas ideias.

Se essa biblioteca fosse sua, o que você gostaria que ela fizesse?

Que funcionalidade você sentiria falta em um cliente HTTP?

E onde você colocaria o limite para ela continuar sendo, de fato, uma biblioteca HTTP?

Pode ser uma ideia simples, absurda ou tecnicamente difícil.

Talvez justamente uma sugestão que eu nunca teria pensado seja o que vai definir a próxima versão do projeto.

Quero ouvir vocês.

Github: https://github.com/PedroFnseca/esp32-http-client
Doc: https://esp32httpclient.com/ (Antes de dar uma sugestão, é legal ver o que já tem)

Carregando publicação patrocinada...
1

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

1

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...