Protobuf tem suporte a LSP
O novo suporte a protocolo de servidor de linguagem (LSP) do Protobuf, da Buf, está gerando um escrutínio renovado tanto do formato quanto de suas ferramentas, especialmente em comparação com JSON, REST e fluxos de trabalho emergentes orientados por LLMs. Comentadores debatem se schemas rígidos e IDLs como o Protobuf estão se tornando menos necessários ou mais críticos em um mundo de modelos probabilísticos, citando trade-offs em desempenho, ergonomia, versionamento e interoperabilidade entre linguagens. O lançamento também levanta questões sobre LSPs versus integrações específicas de IDE, suporte editorial anterior ao Protobuf e até o tom de anúncios corporativos de código aberto.
Papel do Protobuf e dos Schemas na Era dos LLMs
- Alguns argumentam que os LLMs reduzem a necessidade de ferramentas pesadas de schema, monorepos e infraestrutura de microsserviços centrada em protobuf.
- Outros discordam fortemente, afirmando que a geração de código probabilística torna contratos rígidos e compartilhados mais importantes.
- A divergência depende de os sistemas futuros manterem os LLMs “in-band” para comportamento ou tratá-los como auxiliares que ainda repassam para camadas determinísticas e fortemente tipadas.
Protobuf vs JSON: Desempenho e Praticidade
- Um grupo relata que gRPC/protobuf é mais lento e menos confiável do que JSON para alguns clientes Python do Google Cloud, criticando a complexidade, as etapas de build e a ergonomia do protobuf.
- Outros insistem que o protobuf geralmente é mais rápido e mais compacto na rede, e que as vantagens do JSON são usabilidade e ubiquidade, não desempenho.
- Vários observam ressalvas específicas do ecossistema: implementações de JSON altamente otimizadas em JS e implementações fracas de protobuf em Python podem inverter as expectativas de desempenho.
Schemas, Versionamento e Testes
- Os defensores valorizam o protobuf pela troca de dados agnóstica em relação à linguagem, com segurança de tipos, e pelas regras de evolução compatíveis com versões anteriores.
- Alguns afirmam que, se você “entende protobuf”, muitas vezes pode evitar testes entre sistemas porque o comportamento da evolução de schema é previsível.
- Os críticos argumentam que ainda é preciso validação e testes para a lógica de negócio (por exemplo, interdependências entre campos), então o protobuf não elimina as verdadeiras fontes de quebra.
- Esclarecimentos: renomear e reordenar campos é compatível com o wire, desde que os números dos campos e os tipos permaneçam; renumerar ou mover campos para dentro/fora de
oneofs pode ser problemático, especialmente com formatos JSON/texto ou geradores de linguagem específicos.
Abordagem de LSP e Parsing da Buf
- O LSP da Buf é integrado como um subcomando
buf lsp serve, construído sobre o mesmo parser/compiler que alimenta a CLI. - Alguns veem isso como o primeiro LSP de protobuf robusto e completo em relação à especificação; os anteriores são criticados por aceitar proto inválido ou por carecerem de validação completa.
- Há debate sobre a implementação de LSP: reutilizar o parser “real” da linguagem vs parsers separados e tolerantes a falhas (tree-sitter ou personalizados). As opiniões divergem sobre se correção e recuperação de erros podem coexistir em um único parser.
LSPs, IDEs e Experiência do Desenvolvedor
- Alguns dizem que o protobuf já tinha bom suporte em IDEs (por exemplo, plugins para IntelliJ), questionando afirmações de “primeiro suporte moderno”.
- Outros argumentam que ferramentas baseadas em LSP são mais “modernas” por causa da integração agnóstica ao editor, mesmo que plugins profundos de IDE possam ser mais poderosos.
- Uma minoria reclama que LSPs introduzem latência perceptível; outros acham os atrasos negligenciáveis.
- Há especulação de que LSPs/IDEs podem se tornar menos centrais à medida que ferramentas de codificação baseadas em LLM avançam, mas isso continua em disputa.
Tom do Post do Blog
- A formulação original “You’re welcome” no título do post é amplamente percebida como arrogante ou estranha; alguns leitores acham a reação exagerada.
- A empresa mais tarde reconhece a falha, altera o título e adiciona uma edição explicando a intenção e o feedback.