Mover de JSON para Protobuf. Vale a pena?

23

Temos serviços web REST que podem servir XML ou JSON (WCF). Estou brincando com a ideia de implementar o Protobufs. Por quê?

PROS

  1. Menos carga nos servidores.
  2. Tamanho menor da mensagem - menos tráfego.
  3. É mais fácil mudar agora ou mais tarde.

CONS

  1. Precisa ser implementado
  2. Vai ser mais difícil solucionar problemas / detectar mensagens para depuração.
  3. Posso ativar o GZip no servidor e o JSON consumirá tanto tráfego

Qual é a sua sugestão e / ou experiência nisso?

web-services wcf serialization Katit
fonte
1
Eu olhei para a página da Wikipedia e, na verdade, havia mais caracteres por par de valor-chave, então por que a dose tem mensagens menores?
Ramzi Kahil
Por causa da serialização. Os dados binários são exibidos como binários (matrizes de bytes, por exemplo). Além disso, ele não carrega nomes de propriedades em uma mensagem. Eles passam por ordinais da propriedade. developers.google.com/protocol-buffers/docs/encoding#structure
katit
10
Tecnicamente, você respondeu sua própria pergunta, compacta o JSON e termina com ele. Mais importante ainda, você nunca menciona um caso de negócios real para gastar dinheiro e tempo nessa atividade.

Respostas:

39

O valor comercial da sua implementação excede o custo?

Se você implementar, precisará alterar não apenas o servidor, mas todos os clientes (embora você possa suportar os dois formatos e alterar apenas os clientes conforme necessário). Isso levará tempo e testes, o que é um custo direto. E não subestime o tempo necessário para realmente entender os buffers de protocolo (especialmente os motivos para tornar o campo obrigatório ou opcional) e o tempo necessário para integrar o compilador protobuf ao seu processo de construção.

Então, o valor excede isso? Você se deparou com a opção de "nossos custos de largura de banda representam X% de nossas receitas e não podemos suportar isso"? Ou mesmo "precisamos gastar US $ 20.000 para adicionar servidores para suportar JSON"?

A menos que você tenha uma necessidade comercial premente, seus "profissionais" não são realmente profissionais, apenas otimização prematura.

parsifal
fonte
23

mantenho apis e alguém antes de mim adicionou protobuf (porque era "mais rápido"). A única coisa mais rápida é o RTT devido à menor carga útil e isso pode ser corrigido com o JSON compactado com gzip.

A parte que me parece desagradável é o trabalho relativo para manter o protobuf (comparado ao JSON). Eu uso java, então usamos o mapeamento de objetos Jackson para JSON. Adicionar a uma resposta significa adicionar um campo a um POJO. Mas, para o protobuf, tenho que modificar o arquivo .proto e, em seguida, atualizar a lógica de serialização e desserialização que move os dados para dentro / fora dos buffers de protocolo e para os POJOs. Aconteceu mais de uma vez que ocorreu um lançamento em que alguém adicionou um campo e esqueceu de inserir o código de serialização ou desserialização para os buffers de protocolo.

Agora que os clientes implementaram os buffers de protocolo, é quase impossível se afastar.

Você provavelmente pode adivinhar, meu conselho é não fazê-lo.

Kevin
fonte
5
Se você estiver escrevendo um código de (des) serialização para mover os dados de entrada / saída de POJOs, está fazendo errado. Basta usar as classes geradas por protobuf diretamente.
Marcelo Cantos
Eu acho que nesse caso eu estava entrando / saindo de POJOs porque a base de código suportava solicitações / respostas JSON, XML e Protobuf, e como não posso adicionar anotações de Jackson e / ou JAXB a classes geradas por protobuf, e quero para usar os mesmos objetos de modelo em todo o código, não sei se tenho opções para usar apenas as classes geradas. Eu posso ver como isso seria possível se eu estivesse escrevendo, digamos, serviços GRPC que falam apenas de protobuf.
Kevin