Чем он лучше REST API? Из документации gRPC, мы знаем, что это open source фреймворк вызова удаленных процедур. Это позволяет клиенту и серверу устанавливаеть соединение для простого вызова нужных методов. gRPC лучше чем REST? gRPC может работать в точности как REST API используя унарные операции, но в тот момент когда нам понадобится стриминг, gRPC позволит использовать двух стороннее соединение, при этом минуя задержку на парсинг пути и передаваемых аргументов. Как результат, производительность gRPC намного выше чем у REST API. - Используется Protobuf вместо JSON - Базируется на HTTP 2 вместо HTTP 1.1 - Встроенная кодогенерация вместо сторонних решений вроде Swagger - В 7-10 раз быстрее передача сообщений, чем REST API REST API vs gRPC Оба подхода имеют свою нишу. С точки зрения простоты использования, REST является однозначным победителем. Когда разработчики используют RESTP API, все что нужно что-бы создать сервер это фреймворк web сервера. И для тестирования запросов, разработчик может использовать такие бесплатные утилиты как Postman или cURL. Однако, REST довольно прожорливый, он вынуждает гонять по сети слишком много данных, большая часть из которых не структры данных, а overhead сетевого протокола. При использовании REST, разработчики не могут создавать непрерывное подключение, при котором они непрерывно получают данные с сервера. Разработчики должны периодически делать вызов API что-бы получить данные. А вот gRPC спроектирован что-бы поддерживать непрерывный стриминг. gRPC использует протокол HTTP/2, который имеет поддержку стриминга из коробки. Благодаря нему, разработчик просто устанавливает соединение с сервером и сервер непрерывно возвращает данные, сериализованные с помощью Protobuf. Слабостью gRPC является то, что он требует от разработчика гораздо больше знаний и пониманий того что он делает. К тому же, клиент и сервер должны иметь файл .proto, описывающий формат их взаимодействия. Оба используют эту информацию для осуществления кодирования и декодирования запроса и ответа. В отличии от REST, разработчики не могут делать вызов метода вводя URL в браузере. При использовании gRPC, нужно кодировать и декодировать каждый запрос и ответ, согласно формату Protocol Buffers. Это потребляет довольно много ресурсов процессора, но как результат мы получает очень быструю передачу по сети, в сравнении с REST. Стоит ли использовать gRPC? REST изменил архитектуру приложений в тот момент когда был изобретен (это было более 2 десятков лет назад). На сегодняшний день это что-то вроде стандарта по обмену данными между сервисами, под который подстраивается вся экосистема. И даже несмотря на свой проигрыш в скорости, REST по прежнему активно используется в микросервисной архитектуре. А для тех, кому важна скорость передачи данных, есть gRPC. ИТ область слишком большая, что-бы можно было посоветовать какое-то единое решение для всех проектов. Выбирайте то, что вам подходит больше с архитектурной точки зрения. #grpc #rpc #developer #rest #restapi #protobuf
TechLead Nick
Что такое gRPC?
Чем он лучше REST API?
Из документации gRPC, мы знаем, что это open source фреймворк вызова удаленных процедур. Это позволяет клиенту и серверу устанавливаеть соединение для простого вызова нужных методов.
gRPC лучше чем REST?
gRPC может работать в точности как REST API используя унарные операции, но в тот момент когда нам понадобится стриминг, gRPC позволит использовать двух стороннее соединение, при этом минуя задержку на парсинг пути и передаваемых аргументов.
Как результат, производительность gRPC намного выше чем у REST API.
- Используется Protobuf вместо JSON
- Базируется на HTTP 2 вместо HTTP 1.1
- Встроенная кодогенерация вместо сторонних решений вроде Swagger
- В 7-10 раз быстрее передача сообщений, чем REST API
REST API vs gRPC
Оба подхода имеют свою нишу.
С точки зрения простоты использования, REST является однозначным победителем. Когда разработчики используют RESTP API, все что нужно что-бы создать сервер это фреймворк web сервера. И для тестирования запросов, разработчик может использовать такие бесплатные утилиты как Postman или cURL.
Однако, REST довольно прожорливый, он вынуждает гонять по сети слишком много данных, большая часть из которых не структры данных, а overhead сетевого протокола.
При использовании REST, разработчики не могут создавать непрерывное подключение, при котором они непрерывно получают данные с сервера. Разработчики должны периодически делать вызов API что-бы получить данные.
А вот gRPC спроектирован что-бы поддерживать непрерывный стриминг. gRPC использует протокол HTTP/2, который имеет поддержку стриминга из коробки. Благодаря нему, разработчик просто устанавливает соединение с сервером и сервер непрерывно возвращает данные, сериализованные с помощью Protobuf.
Слабостью gRPC является то, что он требует от разработчика гораздо больше знаний и пониманий того что он делает. К тому же, клиент и сервер должны иметь файл .proto, описывающий формат их взаимодействия. Оба используют эту информацию для осуществления кодирования и декодирования запроса и ответа. В отличии от REST, разработчики не могут делать вызов метода вводя URL в браузере.
При использовании gRPC, нужно кодировать и декодировать каждый запрос и ответ, согласно формату Protocol Buffers. Это потребляет довольно много ресурсов процессора, но как результат мы получает очень быструю передачу по сети, в сравнении с REST.
Стоит ли использовать gRPC?
REST изменил архитектуру приложений в тот момент когда был изобретен (это было более 2 десятков лет назад). На сегодняшний день это что-то вроде стандарта по обмену данными между сервисами, под который подстраивается вся экосистема.
И даже несмотря на свой проигрыш в скорости, REST по прежнему активно используется в микросервисной архитектуре.
А для тех, кому важна скорость передачи данных, есть gRPC. ИТ область слишком большая, что-бы можно было посоветовать какое-то единое решение для всех проектов. Выбирайте то, что вам подходит больше с архитектурной точки зрения.
#grpc #rpc #developer #rest #restapi #protobuf