ignat, исполнение всегда можно оптимизировать, бить на весь сайз в рынок — самое неэффективное что можно придумать

dt0wer, упадёт что то в эксепшн или нет — это вопрос конкретной реализации, а не протокола. И большой вопрос что хуже — кинуть ошибку или выплюнуть заведомо неправильные данные

Весьма странное сравнение.

gRPC работает быстрее за счет более нового и производительного стандарта http/2 (обновления данных станут более риалтаймные)

REST вполне себе может работать через http/2

в отличие от REST/WebSockets, у gRPC все данные передаются в бинарном виде, что быстрее и экономнее в плане размера

Вебсокеты поддерживают бинарные данные.

gRPC работает с четкой типизацией, что означает, что сериализация/десериализация происходят «автоматически» и не надо гадать как преобразовывать данные в текст и обратно

При нормальном дизайне rest коннектора — тоже ни о чем гадать не нужно — есть строго типизированный объект, где каждое поле можно однозначно разобрать. Да, писать придется руками (хотя если есть swagger — можно тоже автоматом все сгенерировать)

gRPC это все еще RPC, удаленный вызов процедур, то есть используется все так, будто ты не к удаленному серверу обращаешься, а делаешь вызов на локальной машине.

То что удаленный вызов спрятан ничего не меняет, ровно так же можно все спрятать и для реста

Рис. 6: разбор из строки в объект.

Чтобы разобрать при помощи библиотеки JSON, нам понадобится вручную создать класс, соответствующий ответу сервера:

У вас кровь из глаз от такого не течет? Зачем разбирать сначала в строки, а потом героически их парсить? Почему бы не разобрать сразу в нужные типы?

3Qu, 3-5% больше похоже на гэмблинг. Возможно чтобы нормально исполнять большие сайзы стоило бы подумать про оптимальный экзекьюшн

svgr, 
Вот например пример по картинкам