Mirunie, powiedzcie, czy dobrze myślę, bo już #!$%@? nie wiem.
Co chcę osiągnąć: stworzenie sobie frameworka do pisania i uruchamiania botów na #forex
i teraz tak, mam: - wystawione api platformy tradingowej xStation - konsumera tego api w #python - z api łączy się po websocketach - pan robot, robiący $$$ wykorzystując machine learning
i teraz tak: konsumer subskrybuje sobie po websocketach np eventy "nowa świeca", taki event z api przychodzi co 1 min. Chcę to jakoś przekazać do robota, żeby sobie coś policzył i jak trzeba, to wysłał request do konsumera, który każe api coś zrobić.
[api] ←websockety→ [konsumer] ←???→ [robot]
pytanie zasadnicze: czy jest sens postawienia tego konsumera i robota na np flasku, które będą się komunikować zwykłymi requestami HTTP? Czy skomunikować je websocketami? A może jeszcze inaczej to rozplanować?
Chciałbym to zrobić w miarę prosto, websocketów się dopiero uczę. Chciałbym konsumera wydzielić, żeby go udostępnić, jakby się miał komuś przydać.
@DILERIUM: nie bardzo rozumiem po co "konsumer" (czyli tak naprawdę klient api) ma się komunikować z "robotem" po http czy czymkolwiek innym. Zrób to w formie biblioteki (oddzielony zestaw klas) do tego konkretnego api forexa i użyj jej w swoim robocie. Jak taki kod udostępnisz i np. ja będę chciał sobie pobrać dane z tego api to zrobię w ten sam sposób. Zobacz sobie jak zrobiono klienta do api Twittera: https://github.com/bear/python-twitter
@vans: no klient api, tak nazwałem :P No w sumie na początku miałem to zrobić jako bibliotekę, ale coś mi się odwidziało, chyba ze zmęczenia xD do tego pomyślałem, że skorzystam z flaskowych websocketów, bo z websocket-client mam problem, od razu zamyka mi połączenie, nie tylko ja mam ten problem.
Więc dobra, wracam do opcji zwykłej biblioteki.
dzięki za linka do obserwatora, nie będę musiał wymyślać koła na nowo. w domu
@mirasKo-Kalwario: no nie, zrobiłbym zwykłe api restowe a rabbit czy celery to trochę overkill dla tego zastosowania i niepotrzebne skomplikowanie stacka
@DILERIUM: jak uważasz rest też spoko jeśli wiesz co to jest (zasoby) bo RPC jest wg mnie lepszym rozwiązaniem gdzie poprostu wystawiasz metody które można wywołać
@mirasKo-Kalwario: wiesz, jednak cisnę, żeby to #!$%@? zadziałało jako biblioteka, ale załóżmy, że chciałbym napisać jakiś sposób komunikacji pomiędzy klientem api i robotem. Robot musiałby wystawiać api restowe i to byłoby w miarę prawilne. Leciałyby POSTy zapisywane w bazie i wykorzystywane do obliczeń Api musiałoby przyjmować zapytania RPC. Ja już wolałbym napisać jakieś pseudo json rpc, czyli nazwa akcji do wykonania i jej parametry, w odpowiedzi dostawałbym już prawilny obiekt jak
@DILERIUM: a jak biblioteka bedzie sie skalować? osobny worker jeśli wykonuje wysoko wydajną prace to może potrzebować zasobów i wtedy doskalowujesz worker, jeśli masz to w jednej apce to dokładasz instancji tej appki marnując zasoby na 10 aplikacji tylko po to żeby worker miał zasoby
@mirasKo-Kalwario: Nie sądzę, żeby była potrzeba skalowania. Będzie jeden worker, który będzie trzymał połączenie websocketów i komunikaty wrzucał do callbacka. To wszystko.
Poza tym będę jeszcze kombinować, aby można było sobie kilka wątków odpalić, chociażby dla połączeń na różne adresy. Ale jako webdev nie mam dużego doświadczenia z wielowątkowością, zobaczymy, co z tego się urodzi xD
Co chcę osiągnąć: stworzenie sobie frameworka do pisania i uruchamiania botów na #forex
i teraz tak, mam:
- wystawione api platformy tradingowej xStation
- konsumera tego api w #python - z api łączy się po websocketach
- pan robot, robiący $$$ wykorzystując machine learning
i teraz tak: konsumer subskrybuje sobie po websocketach np eventy "nowa świeca", taki event z api przychodzi co 1 min. Chcę to jakoś przekazać do robota, żeby sobie coś policzył i jak trzeba, to wysłał request do konsumera, który każe api coś zrobić.
[api] ←websockety→ [konsumer] ←???→ [robot]
pytanie zasadnicze: czy jest sens postawienia tego konsumera i robota na np flasku, które będą się komunikować zwykłymi requestami HTTP? Czy skomunikować je websocketami? A może jeszcze inaczej to rozplanować?
Chciałbym to zrobić w miarę prosto, websocketów się dopiero uczę.
Chciałbym konsumera wydzielić, żeby go udostępnić, jakby się miał komuś przydać.
#websocket #programowanie
Jak taki kod udostępnisz i np. ja będę chciał sobie pobrać dane z tego api to zrobię w ten sam sposób.
Zobacz sobie jak zrobiono klienta do api Twittera: https://github.com/bear/python-twitter
No w sumie na początku miałem to zrobić jako bibliotekę, ale coś mi się odwidziało, chyba ze zmęczenia xD do tego pomyślałem, że skorzystam z flaskowych websocketów, bo z websocket-client mam problem, od razu zamyka mi połączenie, nie tylko ja mam ten problem.
Więc dobra, wracam do opcji zwykłej biblioteki.
dzięki za linka do obserwatora, nie będę musiał wymyślać koła na nowo.
w domu
Robot musiałby wystawiać api restowe i to byłoby w miarę prawilne. Leciałyby POSTy zapisywane w bazie i wykorzystywane do obliczeń
Api musiałoby przyjmować zapytania RPC. Ja już wolałbym napisać jakieś pseudo json rpc, czyli nazwa akcji do wykonania i jej parametry, w odpowiedzi dostawałbym już prawilny obiekt jak
Poza tym będę jeszcze kombinować, aby można było sobie kilka wątków odpalić, chociażby dla połączeń na różne adresy. Ale jako webdev nie mam dużego doświadczenia z wielowątkowością, zobaczymy, co z tego się urodzi xD