Spostati da JSON a Protobuf. Ne vale la pena?

Il valore commerciale dell'implementazione supera il costo?

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

Quindi il valore lo supera? Sei di fronte a una scelta tra "i nostri costi per la larghezza di banda sono il X% delle nostre entrate e non possiamo supportarlo"? O anche "abbiamo bisogno di spendere $ 20.000 per aggiungere server per supportare JSON"?

A meno che tu non abbia una necessità aziendale urgente, i tuoi "professionisti" non sono realmente dei professionisti, ma solo un'ottica prematura.

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

La parte che mi è di cattivo gusto è il lavoro relativo per mantenere protobuf (rispetto a JSON). Io uso java così 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 in / out dei buffer del protocollo e in POJO. È successo più di una volta che è accaduto un rilascio in cui qualcuno ha aggiunto un campo e si è dimenticato di inserire il codice di serializzazione o deserializzazione per i buffer del protocollo.

Ora che i client sono implementati rispetto ai buffer del protocollo, è quasi impossibile allontanarsene.

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