quik-lua-rpc
quik-lua-rpc copied to clipboard
Enfernuz
Открытый список вызываемых функций
Здравствуйте! Потребовалось настроить удаленный запуск новой кастомной LUA функции. Пришлось внести правки в 100500+ файлов проекта, но задачку решил и в итоге потерял возможность использовать обновления из репозитория. Было бы здорово, если бы сервис использовал специальный справочник с описанием допустимых функций и параметров. Есть ли какие-нибудь архитектурные ограничения, которые не позволят это реализовать?
Не хочу напрягать, но можете на конкретном примере пояснить, как Вы это видите?
По идее, практически все функции, доступные через сервис, маппятся 1-к-1 к соответствующим функциям в QLua. Бывают иногда различия в типах параметров (для переносимости) или объектах возврата. Само API сервиса, по сути, заключено в .proto-файлах (или JSON-схемах), описывающих сообщения запросов и ответов.
Можете пояснить поля null_flags, value_flags для OnAllTrade? Я полагаю, что value_flags это flags в QLua, но неожиданно натолкнулся на то, что он value_flags бывает пустой. Что такое null_flags?
@gojmpz, это оптимизация для случая, когда в пришедшей от QLua сделке не инициализировано поле flags. Если оставить поле типом int32, то придётся тащить 0 (целое 32-битное число, то есть 4 байта). В случае использования oneof можно заменить сериализацию этого факта 1 байтом (https://stackoverflow.com/a/43696446).
Не хочу напрягать, но можете на конкретном примере пояснить, как Вы это видите?
По идее, практически все функции, доступные через сервис, маппятся 1-к-1 к соответствующим функциям в QLua. Бывают иногда различия в типах параметров (для переносимости) или объектах возврата. Само API сервиса, по сути, заключено в .proto-файлах (или JSON-схемах), описывающих сообщения запросов и ответов.
Я себе представляю это так: добавляем .proto файл с описанием новой функции (например, в специальный пакет custom, по аналогии с пакетом OS), а Lua модули динамически его подхватывают и генерят объекты на основе информации из описания.
P.S. Не судите строго, на Lua никогда не писал, и его возможностей не знаю, поэтому может быть чего-то не догоняю. Ж-)
P.P.S. Я правильно понимаю, что .proto описания и json схемы это альтернативные варианты описания API и сервис может работать с чем-то одним из них?
@gonsalez-ru,
а Lua модули динамически его подхватывают и генерят объекты на основе информации из описания
Проблема в том, что библиотека lua-ptorobuf автоматически генерит только Lua-объекты на основе proto-сообщений. Всю остальную обработку -- то есть, как сервис принимает и обрабатывает такие сообщения (и посылает соответствующие ответные сообщения) -- нужно делать вручную в соответствующих serde-исходниках (для protobuf -- protobuf_request_response_serde.lua). В сущности, большинства такого боилерплейта можно было бы избежать путём использования gRPC, но я не знаю, есть ли сейчас для Lua нормальный генератор grpc-стабов. Когда я начинал разрабатывать проект, такой библиотеки не было.
Я правильно понимаю, что .proto описания и json схемы это альтернативные варианты описания API и сервис может работать с чем-то одним из них?
Это форматы сообщений (запросов и ответов), с которыми работает сервис при выборе соответствующего механизма сериализации и десериализации сообщений. Представленное API одинаково в обоих случаях (ведь цель сервиса -- предоставить доступ к QLua извне). Отличие лишь в том, как сообщения кодируются и декодируются при передаче их от сервиса к клиенту. Protocol Buffers более эффективен с точки зрения размера передаваемых сообщений, но более замороченный в использовании, в то время как JSON более человекочитаем и прост в использовании, но сообщения в этом формате имеют бОльший размер (думаю, даже с учётом использования какого-нибудь алгоритма компрессии типа gzip).