Я патыюсь спроектировать приложение похожее на робингуд для торговли на сток маркет
На данный момент я представляю как это будет работать в общих чертах
Я буду вызывать некоторый API для того чтобы покупать или продовать акции, вот пример чтобы купить (etrade)
https://apisb.etrade.com/docs/api/order/api-order-v1.html#/definition/orderPlace
или (alpaca)
https://alpaca.markets/docs/api-references/trading-api/orders/
Вопрос в том, нужно ли мне иметь свою базу данный с традиционными таблицами например
позиция, ордер купить/продать, пользователь, депозит, итд
каждый раз когда юзер покупает акцию, я буду записывать данные в таблицу БД и вызывать соответствующий API (etrade/alpaca)
Но возникает вопрос нужна ли своя БД вообше если вся это информация уже есть если вызвать API например чтобы
получить список ордеров, позиций итд.
Может быть вызавать напрямую API вендора и вообще не сохранять эту информацию в свою БД, ну может быть за исключением пользователей для аутентикации и их настроек?
Кто что думает?

Здравствуйте, MikhailZ, Вы писали:


MZ>Я патыюсь спроектировать приложение похожее на робингуд для торговли на сток маркет

MZ>Вопрос в том, нужно ли мне иметь свою базу данный с традиционными таблицами например
MZ>позиция, ордер купить/продать, пользователь, депозит, итд
Именно для торговли (приказы на открытие и закрытие позиций) своя база не нужна. Т,е. это вам надо сказать, зачем нужна своя база.
Однако, в API etrade я не обнаружил возможности отслеживать открытые позиции. Таким образом, если ваша программа не хранит информацию об открытых позициях, то и взять её будет негде. В альпаке есть доступ к позициям.

MZ>Может быть вызавать напрямую API вендора и вообще не сохранять эту информацию в свою БД, ну может быть за исключением пользователей для аутентикации и их настроек?
MZ>Кто что думает?
Можно и вызывать, но из приведенных вендоров не у каждого есть такая возможность.
Может быть немного подробнее расскажете о приложении? Для тех, кто не знает о робингуде.

Здравствуйте, MikhailZ, Вы писали:


MZ>Я патыюсь спроектировать приложение похожее на робингуд для торговли на сток маркет
MZ>Кто что думает?

Нужны функциональные (и нефункциональные) требования

Здравствуйте, MikhailZ, Вы писали:


MZ>Я патыюсь спроектировать приложение похожее на робингуд для торговли на сток маркет
MZ>На данный момент я представляю как это будет работать в общих чертах
MZ>Кто что думает?

Чтобы работало достаточно быстро (как я себе представляю такое приложение) надо кэшировать данные локально.
Не обязательно в виде реляционной БД.
Самое напряжное по производительности это графики.

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, MikhailZ, Вы писали:


MZ>>Я патыюсь спроектировать приложение похожее на робингуд для торговли на сток маркет
MZ>>Кто что думает?

Б>Нужны функциональные (и нефункциональные) требования

Требования очень простые, пользователь может купить акции, продать акции и иметь список акций которое он отслеживает
Такое приложение есть у Тинкофф банк и у многих других банков

Здравствуйте, samius, Вы писали:

S>Здравствуйте, MikhailZ, Вы писали:


MZ>>Я патыюсь спроектировать приложение похожее на робингуд для торговли на сток маркет

MZ>>Вопрос в том, нужно ли мне иметь свою базу данный с традиционными таблицами например
MZ>>позиция, ордер купить/продать, пользователь, депозит, итд
S>Именно для торговли (приказы на открытие и закрытие позиций) своя база не нужна. Т,е. это вам надо сказать, зачем нужна своя база.
S>Однако, в API etrade я не обнаружил возможности отслеживать открытые позиции. Таким образом, если ваша программа не хранит информацию об открытых позициях, то и взять её будет негде. В альпаке есть доступ к позициям.

MZ>>Может быть вызавать напрямую API вендора и вообще не сохранять эту информацию в свою БД, ну может быть за исключением пользователей для аутентикации и их настроек?
MZ>>Кто что думает?
S>Можно и вызывать, но из приведенных вендоров не у каждого есть такая возможность.
S>Может быть немного подробнее расскажете о приложении? Для тех, кто не знает о робингуде.



пользователь может купить акции, продать акции и иметь список акций которое он отслеживает
Аналог Тинькофф инвестиции

Здравствуйте, MikhailZ, Вы писали:

MZ>пользователь может купить акции, продать акции и иметь список акций которое он отслеживает
MZ>Аналог Тинькофф инвестиции

Очевидно, хранить информацию как-то придется, хотя бы API ключи пользователей. А судя по тому, что на etrade-е нет вотчлиста, то и вотчлист придется хранить тоже.
Со списком открытых позиций решение не столь очевидно. Думаю, что придется его хранить, но так же его придется постоянно синхронизировать с вендором, т.к. он может меняться даже без активных действий пользователя просто по мере заполнения выставленных приказов. Но это опять к уточнению требований. Должно ли приложение показывать список позиций в реальном времени, или актуализировать его лишь в момент запроса списка позиций пользователем? И что будет делать приложение, если вендор отправил его в бан?

Здравствуйте, MikhailZ, Вы писали:

MZ>Требования очень простые, пользователь может купить акции, продать акции и иметь список акций которое он отслеживает
MZ>Такое приложение есть у Тинкофф банк и у многих других банков

С такими простыми требованиями достаточно иметь один однопоточный сервак и реализовать простой API из трех эндпоинтов.
Что из этого вызывает трудности?

MZ>Кто что думает?
Будет ли встроенный тестер стратегий на истории?
Или чисто в телефоне компульсивному трейдеру на глаз купить-продать потыкать?

Здравствуйте, samius, Вы писали:

S>Здравствуйте, MikhailZ, Вы писали:

MZ>>пользователь может купить акции, продать акции и иметь список акций которое он отслеживает
MZ>>Аналог Тинькофф инвестиции

S>Очевидно, хранить информацию как-то придется, хотя бы API ключи пользователей. А судя по тому, что на etrade-е нет вотчлиста, то и вотчлист придется хранить тоже.
S>Со списком открытых позиций решение не столь очевидно. Думаю, что придется его хранить, но так же его придется постоянно синхронизировать с вендором, т.к. он может меняться даже без активных действий пользователя просто по мере заполнения выставленных приказов. Но это опять к уточнению требований. Должно ли приложение показывать список позиций в реальном времени, или актуализировать его лишь в момент запроса списка позиций пользователем? И что будет делать приложение, если вендор отправил его в бан?

Спасибо, понимаю. Обычно такие приложения стараются показывать все включая позиции в реальном времени насколько это возможно.
Понятно что какие-то данные надо хранить в свой БД, особенно то что связано с пользователями, например настройки, предпочтения, вероятно вотчлисты, как вы заметили.

Меня больше интересует нужно ли сохранить ордер на покупку или продажу в свою БД а потом вызывать внешний API и обновлять статус заказа в своей БД по результатам. Это приведет к необходимости постоянной синхронизации

Второй вариант сразуже вызывать внешний API и не заморачиваться со своей таблицей заказов/ордеров

Здравствуйте, MikhailZ, Вы писали:

MZ>Здравствуйте, samius, Вы писали:

MZ>Меня больше интересует нужно ли сохранить ордер на покупку или продажу в свою БД а потом вызывать внешний API и обновлять статус заказа в своей БД по результатам. Это приведет к необходимости постоянной синхронизации

Пока ордер активен (не заполнен полностью или не отменен), никто даже вендор не может сказать, исполнится ли он в следующую секунду. С какой периодичностью опрашивать у вендора неисполненные ордера — нужно решать, учитывая разные соображения, включая трафик и допустимую частоту обновления в API вендора.


MZ>Второй вариант сразуже вызывать внешний API и не заморачиваться со своей таблицей заказов/ордеров
Вызвать внешний API можно, но далеко не всегда ответ сможет прояснить ситуацию. Например, что бы только перечислить неисполненные ордера, нужно вызвать API множество раз, каждый раз указывая интересующий статус (OPEN, EXECUTED, CANCELLED, INDIVIDUAL_FILLS, CANCEL_REQUESTED, EXPIRED, REJECTED). И каждый вызов может привести к paging, т.е. придется вызвать множество раз.
Ну и дебильный API не позволяет проверять наличие изменений, как, например, это делает gmail API. Каждый раз придется сканировать состояние ордеров заново, что бы, например, узнать, не появились ли новые ордера, не отменились ли старые.

S>Пока ордер активен (не заполнен полностью или не отменен), никто даже вендор не может сказать, исполнится ли он в следующую секунду. С какой периодичностью опрашивать у вендора неисполненные ордера — нужно решать, учитывая разные соображения, включая трафик и допустимую частоту обновления в API вендора.


S>Вызвать внешний API можно, но далеко не всегда ответ сможет прояснить ситуацию. Например, что бы только перечислить неисполненные ордера, нужно вызвать API множество раз, каждый раз указывая интересующий статус (OPEN, EXECUTED, CANCELLED, INDIVIDUAL_FILLS, CANCEL_REQUESTED, EXPIRED, REJECTED). И каждый вызов может привести к paging, т.е. придется вызвать множество раз.
S>Ну и дебильный API не позволяет проверять наличие изменений, как, например, это делает gmail API. Каждый раз придется сканировать состояние ордеров заново, что бы, например, узнать, не появились ли новые ордера, не отменились ли старые.


Спасибо за идею. Я думаю оптимально будет сохранять ордер в БД а потом вызывать внещний API и синхронизировать статусы по мере их изменения OPEN->PENDING->EXECUTED, etc. Фронтенд через некоторый сервис будет читать данные из таблицы ордеров