Przejdź z JSON do Protobuf. Czy warto?

23

Mamy usługi sieciowe REST, które mogą obsługiwać XML lub JSON (WCF). Bawię się pomysłem wdrożenia Protobufów. Czemu?

PROS

Mniejsze obciążenie serwerów.
Mniejszy rozmiar wiadomości - mniejszy ruch.
Łatwiej jest zmienić teraz niż później.

CONS

Konieczne do wdrożenia
Będzie trudniej rozwiązywać problemy / wąchać wiadomości do debugowania.
Mogę włączyć GZip na serwerze, a JSON będzie zużywał tyle ruchu

Jakie są twoje sugestie i / lub doświadczenia w tym zakresie?

web-services wcf serialization

— katit
źródło

1

Spojrzałem na stronę wikipedii i w rzeczywistości było więcej znaków w parze klucz-wartość, więc po co dawać mniejsze wiadomości?

— Ramzi Kahil

Z powodu serializacji. Dane binarne przechodzą jako dane binarne (na przykład tablice bajtów). Ponadto nie zawiera nazw właściwości w wiadomości. Idą według porządków własności. developers.google.com/protocol-buffers/docs/encoding#structure

— kat

10

Technicznie odpowiedziałeś na swoje pytanie, skompresuj JSON i skończ z nim. Co najważniejsze, nigdy nie wspominasz o uzasadnieniu biznesowym dotyczącym wydawania pieniędzy i czasu na tę działalność.

39

Czy wartość biznesowa ich wdrożenia przekracza koszty?

Jeśli wdrożysz, musisz zmienić nie tylko serwer, ale wszystkich klientów (chociaż możesz obsługiwać oba formaty i zmieniać klientów tylko w razie potrzeby). To zajmie trochę czasu i testów, co jest bezpośrednim kosztem. I nie lekceważ czasu potrzebnego na prawdziwe zrozumienie buforów protokołów (szczególnie powodów, dla których pole jest wymagane lub opcjonalne), a także czasu potrzebnego na zintegrowanie kompilatora protobuf z procesem kompilacji.

Czy wartość przekracza to? Czy masz do wyboru opcję „nasze koszty przepustowości stanowią X% naszych przychodów i nie możemy tego wesprzeć”? A może nawet „musimy wydać 20 000 $, aby dodać serwery do obsługi JSON”?

Jeśli nie masz pilnej potrzeby biznesowej, twoi „profesjonaliści” nie są tak naprawdę profesjonalistami, tylko przedwczesną optymalizacją.

— parsifal
źródło

23

utrzymuję apis i ktoś przed mną dodał protobuf (ponieważ był „szybszy”). Jedyną rzeczą, która jest szybsza, jest RTT ze względu na mniejszy ładunek, który można naprawić za pomocą gzipped JSON.

Niesmaczna jest dla mnie względna praca nad utrzymaniem protobuf (w porównaniu do JSON). Używam java, więc używamy mapowania obiektów Jacksona dla JSON. Dodanie do odpowiedzi oznacza dodanie pola do POJO. Ale w przypadku protobuf muszę zmodyfikować plik .proto, a następnie zaktualizować logikę serializacji i deserializacji, która przenosi dane do / z buforów protokołu do POJO. Niejednokrotnie wydarzyło się wydanie, w którym ktoś dodał pole i zapomniał wstawić kod serializacji lub deserializacji dla buforów protokołu.

Teraz, gdy klienci zaimplementowali bufory protokołów, prawie niemożliwe jest uciec.

Prawdopodobnie można się z tego domyślić, moja rada nie rób tego.

— Kevin
źródło

5

Jeśli piszesz (de) kod serializacji, aby przenieść dane do / z POJO, robisz to źle. Wystarczy użyć klas wygenerowanych bezpośrednio przez protobuf.

— Marcelo Cantos,

Wydaje mi się, że w tym przypadku przeprowadzałem się do POJO, ponieważ baza kodu obsługiwała zarówno żądania JSON, XML, jak i Protobuf, i biorąc pod uwagę, że nie mogę dodawać adnotacji Jacksona i / lub JAXB do klas generowanych przez protobuf i chcę aby użyć tego samego obiektu modelu w całym kodzie, nie wiem, czy mam opcje, aby po prostu użyć wygenerowanych klas. Widzę, jak byłoby to możliwe, gdybym pisał, powiedzmy, że usługi GRPC mówią tylko protobuf.

— Kevin,