[mirunek]

Siema #programowanie mirki.
Chcę użyć RabbitMQ, moje API będzie wysyłało message do kolejki, consumer ma to obsłużyć (zebrać dane). I teraz moje pytanie: czy consumer może tworzyć kolejny message (który wrzuci do kolejki - prawdopodobnie innej), który zwróci informacje do API (celu zapisania do bazy danych itd.)? Jeśli nie, to jak inaczej to obsłużyć?

#php #symfony

[mirunek]

@Resuscytacja: czy to jest dobre, że consumer / worker (sam nie wiem jak to nazywać, znalazłem różne użycia) będzie miał bezpośredni dostęp do bazy danych? Co jeśli odpalę 20 instancji takich consumerów (ten sam kod, osobne instancje)? Chyba wolałbym mieć jedno miejsce, które ma dostęp do bazy danych itd.

Ale dzięki za odpowiedź, rozważę to :)

[Resuscytacja]

@mirunek: usunąłem wiadomość, bo za późno się skaplem, że chodzi o php. W Pythonie w apkach webowych każdy consumer ma dostęp do bazy danych

[mirunek]

@Resuscytacja ok, rozumiem :) jeśli chodzi o język to tutaj chyba nie ma znaczenia. Worker byłby w nodejs.

Druga sprawa, co jeśli zmieni się struktura bazy danych? Worker który miałby dostęp do bazy danych musiałby również obsłużyć te sytuacje.

[Resuscytacja]

@mirunek: przy zmianie struktury bazy robimy migrację na każdej instancji. Ale to robi się automatycznie, na przykład przy pomocy fabrica

[D.....a]

@mirunek klient może wysłać zapytanie do API, które zwraca mu zadanie, a w odpowiedzi wysyłać inne zapytania do API, które po prostu zapisze sobie dane przekazane.

[mch0588]

@mirunek: 1. trochę mieszasz operacje synchroniczne z asynchronicznymi. Zakładam, że mówisz o Http API więc flow jest taki Klient -> Api -> Wysłanie wiadomości na kolejkę -> Zwrócenie odpowiedzi przez API do klienta, w tym samym czasie consumer zgarnia wiadomość z kolejki i ją może obsłużyć ale "api request" już się skończył :)

2. Tak, to jest ok gdy consumer wysyła kolejną wiadomość. Powiedzmy, że masz event, że liczba zamówień

[mirunek]

@mch0588 raz na dobę mają zostać pobrane dane z podanych stron. Pewnie ustawie jakiś cron, który wygeneruje i wyśle wiadomości do kolejki, a consumer bedzie czekal i zbieral dane ze stron. Ale dalej muszę te zebrane zapisać.

Odnośnie pkt. 3, tak wiem tylko tu chodziło o to że kiepsko to chyba wygląda jeśli każda z instancji ma dostęp bezpośrednio do bazy danych.

[aso824]

@mirunek: pkt 3 - dlaczego? Bo współbieżność? Jak masz wiele requestów na raz to masz dosyć podobne problemy i wyzwania jak przy odpaleniu wielu consumerów na raz.
Chyba że masz na myśli wiele różnych consumerów, jeszcze w innym języku, to faktycznie lepiej oddelegować zapis do "głównego" consumera - przede wszystkim z powodu prostoty zarządzania schematem bazy danych itp.

Druga sprawa, co jeśli zmieni się struktura bazy danych? Worker który miałby

[eloar]

@mirunek: jasne, czemu nie miałbyś zrobić 2kierunkowej komunikacji na kolejkach. to całkiem spoko opcja moim zdaniem

[Krolik]

3. jeżeli odpalisz 20 konsumerów to będziesz miał skalowalność i tyle :)

@mch0588: zawsze mnie rozwala jak firemki generujące 5 raportów dziennie, mające 100 klientów, których obsłużenie poszłoby na RaspberryPi nano oprogramowanym w Scratchu, budują architektury aplikacji jakby były drugim Google xD. Kolejki? Skalowalność? YAGNI.

[mch0588]

@Krolik: lol, ale ja nie mówię, że tak trzeba tylko taka jest zawsze opcja xD