REST — это письмо почтой. gRPC — это телефонный звонок. Когда 1С нужен мгновенный ответ

Платёжный шлюз, скоринг, антифрод - в таких интеграциях 1С часто работает не в режиме «отправили и забыли», а ждёт синхронный ответ за десятки или сотни миллисекунд. В этот момент привычный REST на JSON может стать не просто способом интеграции, а узким местом: текстовая сериализация, вольные контракты, накладные расходы HTTP-вызовов, сложность контроля совместимости API. gRPC - это не «быстрый REST», а другой подход к синхронным вызовам. Бинарный Protocol Buffers вместо текстового JSON. HTTP/2 и мультиплексирование вместо классической модели последовательных HTTP-запросов. Строгие protobuf-контракты вместо неформального описания JSON. Стриминг в обе стороны вместо «запрос-ответ». В этом докладе я покажу: • Почему REST может становиться узким местом в high-load синхронных интеграциях, и где заканчивается зона его удобства • Как работают protobuf, HTTP/2 multiplexing и gRPC streaming • Чем protobuf-контракты полезны как единый источник истины: изменил .proto -> компилятор показал где сломалось • Архитектуру «1С -> HTTP-прокси -> gRPC-сервис»: где остаётся 1С, где появляется gRPC-контур, как версионировать контракты • Как корректно сравнивать REST и gRPC: latency, p95, throughput, размер payload, keep-alive, concurrency • Реальные результаты бенчмарка: 1000 запросов/сек, p95: 200 мс vs 25 мс, throughput: 800 vs 5000 req/s • Когда gRPC действительно нужен, а когда REST проще, дешевле и достаточен • Дам репозиторий: gRPC-сервер на Go, клиент на Python, protobuf-контракты, REST-эндпоинты для сравнения, бенчмарк с графиками latency и throughput