В архитектуре API принято считать REST стандартом, но когда мы говорим о взаимодействии микросервисов внутри системы, REST начинает буксовать. Основная проблема в том, что REST заставляет нас мыслить сущностями: User, Order, Payment. Мы манипулируем этими ресурсами.
gRPC (Remote Procedure Call) возвращает нас к логике прямого действия. Вам не нужно думать, какой HTTP-метод прикрутить к ендпоинту — вы просто вызываете удаленный метод
CreateUser() так же естественно, как если бы он лежал в соседнем файле вашего проекта.Подкапотка HTTP/2 и бинарный стриминг
gRPC — это не просто другой формат запросов, это другой фундамент. В отличие от классического REST, gRPC по дефолту работает на HTTP/2. Это дает нам две критические для продакшена вещи:
1. Мультиплексирование. Мы не открываем новое соединение на каждый чих. Множество запросов летят по одному каналу, что избавляет сеть от лишней нагрузки и оверхеда на установку соединений.
2. Стриминг. В REST передача потока данных без костылей вроде WebSockets практически невозможна. В gRPC клиент может стримить данные серверу, сервер — клиенту, или они могут делать это одновременно (бидирекциональный стриминг). Для распределенных систем, где нужно прокидывать тяжелые логи или real-time данные, это прям спасение.
Схема как закон: Протофайлы против документации
В REST описание схемы API через Swagger — это часто жест вежливости со стороны бэкенд-разработчика. В gRPC схема (proto-файлы) — это обязательный контракт. Вы описываете методы и типы данных в файлах
.proto, а затем gRPC сам генерирует клиентский код и типизированные шаблоны для сервера.Вам же остается только вписать бизнес-логику и походы в базу. Такой подход исключает ситуацию, когда фронт ожидает
string, а бэк внезапно прислал null или int. Если данных нет в схеме — считай их нет и вовсе.Почему байты быстрее текста
Самое наглядное различие между REST и gRPC — это способ упаковки данных. REST гоняет JSON. Это текстовый формат: куча кавычек, скобочек и повторяющихся имен полей. Это как перевозить мебель в полностью собранном виде. Красиво, понятно, но занимает чертовски много места в грузовике.
gRPC использует Protobuf — бинарный формат. Это плоские коробки из IKEA. Мы передаем только голые значения в строгом порядке, зашифрованные в байты. Чтобы «собрать» эту мебель на другом конце, у принимающей стороны должна быть инструкция — тот самый proto-файл. Без него эти байты — просто мусор, но с ним скорость парсинга и передачи данных возрастает в разы.
Где gRPC бесполезен, а где незаменим
У gRPC есть существенный ограничитель: браузеры не умеют полноценно с ним работать. Вы не сможете просто так постучаться из Chrome в gRPC-бэкенд без специальных прокси-прослоек. Поэтому gRPC — это не про публичные API для фронтенда, а про внутреннюю кухню.
Когда у вас сотни микросервисов, которые должны общаться друг с другом с минимальными задержками, gRPC становится идеальным клеем. Он создает иллюзию бесшовности: вы вызываете функции другого сервиса, находящегося на другом конце дата-центра, с той же легкостью, что и локальные методы. В высоконагруженных системах, где борьба идет за миллисекунды, экономия на парсинге JSON и эффективное использование соединений HTTP/2 — это единственный способ не положить сеть.
🔥 — если пост был понятен и полезен.
А если остались вопросы или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!
10МДК | ВЕБМастер