Comments 3
Хорошая статья, даёт повод задуматься. Я поначалу думал, зачем мне gRPC, json и так работает. Сейчас же подумалось, что этот аргумент как у любителей Windows XP.
Как-то не убедили без цифр. Ну хотя бы RPs, mem/cpu usage до и после.
Единственное что подкупает это то, что сериализация должна быть быстрей. Мы же любим все быстрое Ж) Но и тут я не уверен что это правило работает для всех платформ. (https://medium.com/@onufrienkos/benchmarking-performance-grpc-vs-rest-on-node-js-bf766127f170)
И что больше всего пугает это то, что старый ламповый RPC не очень то и популярен в связи с проблемами которые он приносит с собой. Почему же так хайпят на gRPC?
Хотелось бы видеть реальную пользу :/
- HTTP/2 не обязывает использовать gRPC
- Даже до HTTP/2 можно keep-alive попробовать
- Генерить типы для разных языков можно и со свагера
Единственное что подкупает это то, что сериализация должна быть быстрей. Мы же любим все быстрое Ж) Но и тут я не уверен что это правило работает для всех платформ. (https://medium.com/@onufrienkos/benchmarking-performance-grpc-vs-rest-on-node-js-bf766127f170)
И что больше всего пугает это то, что старый ламповый RPC не очень то и популярен в связи с проблемами которые он приносит с собой. Почему же так хайпят на gRPC?
Хотелось бы видеть реальную пользу :/
У gRPC отсутствует главный плюс json-а — человекочитаемое сообщение.
Скорость — это, конечно, хорошо, но только до первых разборок, почему пришедший массив бинарных данных не был корректно распознан.
Скорость — это, конечно, хорошо, но только до первых разборок, почему пришедший массив бинарных данных не был корректно распознан.
Sign up to leave a comment.
Миграция API с REST на gRPC в WePay