investAPI
investAPI copied to clipboard
Tinkoff
WebSocket proxy (json_proto) проблемы
Время в orderbook.time возвращается в строковом формате вместо timestamp, аналогичные проблемы в candle с time и last_trade_ts. Также дает знать о себе старая проблема. Можно конечно же откостылить у себя, но если задаться целью получать не только "сообщения c наименованиями полей идентичными наименованиям полей из proto-контрактов", но и одинакового типа, то есть над чем поработать. Скорее всего аналогичные проблемы в других WebSocket стримах - не проверял.
Совсем мелочь - пока никто не начал пользоваться WS Proxy, имеет смысл добавить payload в сообщения - для полной совместимости структуры возвращаемых данных с данными gRPC стримов.
эти ограничение вызваны текущей реализацией прокси - тк контракты транслируются с grpc protobuf строковое представление в json для timestamp https://cloud.google.com/ruby/docs/reference/google-cloud-container-v1/latest/Google-Protobuf-Timestamp#json-mapping c payload получилось трансляция oneof из grpc контрактов в openapi json действительно потерялись но в данной реализации это не похоже на проблему
эти ограничение вызваны текущей реализацией прокси
Да мне все равно, чем вызваны ограничения
это не похоже на проблему
и похожи ли они на проблему. Я уже давно понял, что разработчикам API Tinkoff Инвестиций не присуще чувство прекрасного, и, как закономерный финал, не приходится говорить ни о каком "бесшовном" переходе на использование WebSocket Proxy в своем коде.
напишите пожалуйста какую проблему вы решаете и об каком "бесшовном" переходе речь?
Попробуйте себе представить проект в десяток тысяч строк кода, использующий определенную структуру данных, получаемых с gRPC-стримов InvestAPI. Вдруг появляется интересная альтернатива в виде WebSocket-стримов, поставляющих те же самые данные, но уже в виде структур иной формации. Внимание, вопрос: в каком случае придется минимально переписывать код - в случае с идентичными или в случае с малопохожими друг на друга структурами? Время пошло....
А теперь серьезно: если вот эта шняга, за которую здесь жуется уже вторую неделю, тебе не по силам, то есть смысл задуматься о смене работы. Тебе вполне бы подошел оранжевый жилет и лопата в руках при укладке асфальта.
Друг - твоя токсичность не помогает в решении проблемы Можете нормально сформулировать проблему? Или хотябы ответь нормально на вопросы Свои 10к строк кода ты руками написал и жалуешься тут что тебе не переключить протокол? WebSocket - это не интересная альтернатива а отдельный протокол более убогий имхо чем grpc, но сделан в например, чтобы в бразуре можно было нарисовать график, или подключить какуюто беду которая не умеет grpc
И еще друг не все вокруг шняга, если ты такой умный приходи на собеседования если знаешь другие слова кроме шняга, если пройдешь собес я сразу за лопату и копать
да я согласен что 10 минут, только понять бы что требуется и точно ли проблема у меня добавить в структур payload - зачем это бесполезное поле.. и лишние байты в сообщении... - кроме совместимости с какимто другим кодом который возможно вообще не от той стенки гвоздь. либо же если это dto из grpc то вы можете замапить json из websocket в эти объекты - это может делать сам protobuf-json, вообще не вижу проблем - какую вы видите ошибку? как ее повторить пришлите пожалуйста пример, из ваших оценок действительности ничего не понятно
На payload я уже не настаиваю, но ради совместимости можно было бы и пожертвовать лишними байтами - ни вижу здесь никакого криминала. Главная проблема в том, что поля в возвращаемых структурах gRPC и WebSocket-стримов, хоть и имеют одинаковые наименования, но к сожалению, разных типов. Если честно, то я давно и без проблем нормализовал для себя (привел в соответствие) структуру данных, возвращаемых WebSocket MarketData стримом. Positions и Portfolio не стал пока трогать, в надежде на то, что разработчики смогут доставлять данные "один в один" как в gRPC.
1 в 1 не получается тк gRPC это бинарный протокол и передача там таймастампа обусловлена размером полей целых чисел. В случае с json когда мы информацию передаем текстом представление таймстампа какой вариант лучше и почему? ` 2023-08-02T17:09:55Z
{"seconds":1690996195,"nano":0} `
- потратить время на пересборку сообщения чтобы добавить поле payload и преобразовать строки в объекты
какой вариант лучше
Любой из этих двух лучший, если используется только он один в gRPC и WebSocket. Какой смысл был мутить WebSocket json_proto стрим, если он не стал идентичным gRPC по структуре возвращаемых данных?
- потратить время на пересборку сообщения чтобы добавить поле payload и преобразовать строки в объекты
именно так я и сделал) Но мог бы с таким же успехом пересобрать и сообщения WebSoсket-стрима в первоначально предложенном разработчиком варианте. Мне не трудно. Гораздо труднее объяснить, чем шедевр мастера отличается от колхоза тяп-ляпщика.
Ну тут спора не получится, что выглядит не красиво, json-proto вроде по твоей просьбе и делали и только ты его и пользуешь. Я бы на твоем месте и не писал никаких репортов об проблеме просто попровил спокойно сам и привет. Тут достаточно почитать пару твоих комментариев чтобы понять что нас посетил мастер а не сельпо
Там где вы все учились, я преподавал. Какой собес ты мне предлагаешь?) Я сам подобных бедолаг постоянно отбираю, но молодежь сейчас далеко не та, что в мои времена... Просьба, впредь, называть меня Мастер, и никак иначе. Когда узнаешь, рано или поздно, кто я - будешь хвастаться детям и внукам, что я тебе разрешил так ко мне обращаться.
Тут понятно что у вас серьезный случай Обновления по таймастампам скоро доедут
json-proto вроде по твоей просьбе и делали и только ты его и пользуешь.
не удивлюсь, если я вообще единственный WebSocket proxy затестил на данный момент. Но если сделать все по уму, то мои последователи не раз поблагодарят разработчиков от души
Обновления по таймастампам скоро доедут
там еще одна проблема, кроме TS
И самое главное: если это только для меня, то можно не делать - сегодня же закрою issue. А вот если есть хоть немного понимания, что необходимо обеспечить единство форматов данных WebSocket и gRPC-стримов для легкого старта работы с WebSocket proxy, то конечно же жду в скором будущем обновления.
с последним обновлением возможно что и эта проблема пройдет, но еще возможно что всплывут и другие неожиданности
gRPC данные всегда с полем nano, даже если значение равно 0.
Предлагаю байты не экономить, совместимость важнее. И payload предлагаю тоже начать использовать, пусть только в json_proto. Там работы лишь на строку кода: msg.payload = Object.keys(msg)[0];
в итоге получается помоему очень убого, но мне к сожалению мне не понять мысли мастера сельпо пту для бедолаг
убогость заключается в том что теперь в json будует все поля с дефолтными значениями -если они не указаны - по словам мастера это в grpc значения содержатся, хотя видимо мастер гуманитарных направлений не разбирает протоколы и в чем отличия json от protobuf
Не расстраивайся сильно. я сделаю из тебя джуна, как минимум. Мастер пока отталкивается от того, что ему отдает SDK для Node JS. Убедишь Мастера, что там что-то не так, и что другие SDK возвращают без nano, можно будет обсудить. А пока делай, за что тебе деньги платят, пока я в хорошем настроении.
Друг, так и хочется тебе сказать иди делай уроки, а свои фантазии оставь для других пабликов - писателей-фантастов
Ученик, ты уж определись, можешь ли ты сделать полное подобие структуры gGPRC или нет? Если нет, то не имеет смысла мучать себя и других: json_proto можешь убить за ненадобностью тогда. А если можешь - стисни зубы и делай.
и скорей всего json_proto просто удалим потом - либо придется обратно убрать дефолтные значение - потомучто смысла в них нет, поразвлекаемся с гуманитариями над совместимостью и пока
очень жаль, что ты так и не понял, в чем смысл реализации json_proto( А то что она будет с небольшими костылями на бэкенде, отобьется много раз сэкономленным временем на фронтах пользователей. Все ради удобства конечного пользователя, не более того
да просветите плиз, в чем заключается удобство? развне недостаточно использовать https://github.com/googleapis/proto3-json-serializer-nodejs чтобы распарсить json в нужный вам протобуф на nodejs, даже в протоколе json, а не json_proto? тут какраз json_proto поделка которая вернет результат не совместимы со специфакаицияей protobuf-json тоесть имеет проблемы с переносимость в другие платформы