Passa da JSON a Protobuf. Ne vale la pena?

23

Abbiamo servizi web REST che possono servire XML o JSON (WCF). Sto giocando con l'idea di implementare Protobufs. Perché?

PROFESSIONISTI

Meno carico sui server.
Dimensioni del messaggio inferiori - meno traffico.
È più facile cambiare ora che in seguito.

CONS

È necessario implementarlo
Sarà più difficile risolvere / annusare i messaggi per il debug.
Posso abilitare GZip sul server e JSON consumerà tanto traffico

Qual è il tuo suggerimento e / o esperienza su questo?

web-services wcf serialization

— katit
fonte

1

Ho guardato la pagina di Wikipedia e in realtà c'erano più caratteri per coppia chiave-valore, quindi perché dosare ha messaggi più piccoli?

— Ramzi Kahil,

A causa della serializzazione. I dati binari arrivano come binari (ad esempio array di byte). Inoltre, non contiene nomi di proprietà in un messaggio. Vanno per ordinali di proprietà. developers.google.com/protocol-buffers/docs/encoding#structure

— katit

10

Tecnicamente hai risposto alla tua domanda, comprimi il JSON e finisci. Soprattutto non menzionate mai un caso aziendale reale per spendere soldi e tempo in questa attività.

39

Il valore commerciale dell'implementazione supera i costi?

Se si implementa, è necessario modificare non solo il server, ma tutti i client (sebbene sia possibile supportare entrambi i formati e cambiare client solo se necessario). Ciò richiederà tempo e test, il che è un costo diretto. E non sottovalutare il tempo impiegato per comprendere veramente i buffer di protocollo (in particolare i motivi per rendere il campo obbligatorio o facoltativo) e il tempo impiegato per integrare il compilatore protobuf nel processo di compilazione.

Quindi il valore supera quello? Sei di fronte a una scelta di "i nostri costi di larghezza di banda sono l'X% dei nostri ricavi e non possiamo supportarli"? O addirittura "dobbiamo spendere $ 20.000 per aggiungere server per supportare JSON"?

A meno che tu non abbia un'esigenza aziendale urgente, i tuoi "professionisti" non sono in realtà professionisti, solo ottimizzazione prematura.

— parsifal
fonte

23

mantengo l'apis e qualcuno prima di me ha aggiunto protobuf (perché era "più veloce"). L'unica cosa più veloce è RTT a causa del payload più piccolo e che può essere risolto con JSON compresso con gzip.

La parte che è di cattivo gusto per me è il lavoro relativo per mantenere il protobuf (rispetto a JSON). Uso java, quindi usiamo la mappatura degli oggetti Jackson per JSON. Aggiungere a una risposta significa aggiungere un campo a un POJO. Ma per protobuf devo modificare il file .proto, quindi aggiornare la logica di serializzazione e deserializzazione che sposta i dati dentro / fuori dai buffer del protocollo e nei POJO. È successo più di una volta che è avvenuta una versione in cui qualcuno ha aggiunto un campo e ha dimenticato di inserire il codice di serializzazione o deserializzazione per i buffer di protocollo.

Ora che i client hanno implementato i buffer di protocollo, è quasi impossibile evitarlo.

Probabilmente puoi indovinare da questo, il mio consiglio è di non farlo.

— Kevin
fonte

5

Se stai scrivendo (de) codice di serializzazione per spostare i dati dentro / fuori dai POJO, lo stai facendo in modo sbagliato. Usa direttamente le classi generate da protobuf.

— Marcelo Cantos,

Penso che in quel caso mi stavo muovendo dentro / fuori dai POJO perché la base di codice supportava richieste / risposte JSON, XML e Protobuf e dato che non posso aggiungere annotazioni Jackson e / o JAXB alle classi generate da protobuf e voglio per utilizzare gli stessi oggetti modello in tutto il codice, non so di avere opzioni per usare solo le classi generate. Vedo come sarebbe possibile farlo se scrivessi dire servizi GRPC che parlano solo di protobuf.

— Kevin,