No REST for the Wicked - Первые впечатления от gRPC с точки зрения алготрейдера

Рис.1: Ответ gRPC сервера на любой вопрос.

Краткое содержание для непрограммистов: gRPC круто и быстро и знать об этом незачем. Всего хорошего!

При написании коннектора к любой бирже на 99% везде используется два основных вида способа передачи запросов и получения данных — это через отдельные REST-вызовы (например, «биржа, дай мне список инструментов») и через веб-сокеты (например, «биржа, дай мне поток обезличенных сделок по Газпромнефти»).

В этих «обычных» случаях всё общение происходит через JSON-запросы, то есть, говоря по-русски, в текстовом виде.


Рис. 2: пример запроса списка продуктов и ответа рептилоидов с сервера BitGet

Запросы нужно отсылать по заранее известным адресам API.


Но время от времени появляются необычные протоколы и вот у Тинькофф инвестиций попался gRPC.

Лезем в гугл разбираться что это за зверь и выясняем:


Рис. 3: мой стек длиннее твоего.

* gRPC работает быстрее за счет более нового и производительного стандарта http/2 (обновления данных станут более риалтаймные)
* в отличие от REST/WebSockets, у gRPC все данные передаются в бинарном виде, что быстрее и экономнее в плане размера
* gRPC работает с четкой типизацией, что означает, что сериализация/десериализация происходят «автоматически» и не надо гадать как преобразовывать данные в текст и обратно
* gRPC это все еще RPC, удаленный вызов процедур, то есть используется все так, будто ты не к удаленному серверу обращаешься, а делаешь вызов на локальной машине.

Много непонятных букв, но давайте приведу один практический пример.


Рис. 4: меняем пару буковок в строчке, которую отравляем на сервер.

Например, нам нужно получить информацию о доступных бумагах на сервере.

REST-запрос на Битгете будет выглядеть примерно так: GET запрос на адрес api.bitget.com/api/spot/v1/public/products

или в коде:


Рис. 5: Запрос доступных бумаг в OsEngine (коннектор Битгет)

Здесь мы видим сначала формирование запроса, отправку, а потом десериализацию ответа (это когда из текста мы создаем объекты данных).
Дальше объекты передаются в UpdateSecurity, где происходит окончательное формирование полей:


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

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

Рис. 7: Разработчик сделал класс, где строки ответа разложены по полочкам.

Но при этом приходится в коде приводить все к правильным типам данных.

А теперь посмотрим как все делается в gRPC?


Рис. 8: перерыв на обед.

В gRPC всё известно заранее благодаря .proto файлам, в которых описаны методы, предоставляемые сервером:



Рис. 9: методы получения данных по инструментам из instruments.proto Тинькофф инвестиций.

Эти прото-файлы скачиваются с сайта брокера и подключаются в проект.
А дальше происходит небольшая магия.

Из этих прото-файлов компилятор Protobuf генерит файлы с нужными функциями и объявлениями классов. Всё, что нужно, чтобы пользоваться API.
В отличие от REST, тут эти функции/типы не нужно писать самому.

Просто начинаем их использовать:


Рис. 10: получаем список акций.

То есть тип SharesResponse, InstrumentsRequest, метод Shares — все это было сгенерировано автоматически из прото-файлов.

В результате мы получаем ответ с набором объектов, у которых уже объявлены типы данных:

Рис. 11: Заполняем новый объект бумаги в коннекторе OsEngine/Tinkoff

Стоит обратить внимание, что разбираются уже объекты типа Share и да, его определение тоже было автоматом сгенерировано из прото-файла.

А еще в gRPC есть потоковая передача, которая по обещаниям должна работать лучше и быстрее вебсокетов. Но для начального знакомства это уже слишком (:

До встречи в следующем эпизоде!