[m.....y]

Zagadnienie z architektury, jakie jest Wasze zdanie.

Do usługi "odpowiadającej" strzela usługa "pytająca" po http.
Usługa "odpowiadająca" zażyczyła sobie więcej danych, które produkuje usługa "pytająca". Jak usługa "pytająca" powinna przekazywać te dane usłudze "odpowiadającej"?

1. W body requestu.
Załóżmy, że te dane są ogromneee, to wtedy chyba nie wypada ładować to po http?
A co jeśli inna usługa "pytająca", który nie produkuje tych nowych danych, będzie chciała skorzystać z usługi "odpowiadającej"? Będzie musiała najpierw strzelić do usługi produkującej te dane i dopiero do usługi "odpowiadającej".
Wg mnie do dupy.

2. Przez tabelę.
WTF
Pierwszy raz widzę, by microserwisy się komunikowały przez tabelę, ale padł taki pomysł.
Usługa "pytająca" produkując te nowe dane zapisze je w publicznej tabeli, którą potem usługa "odpowiadająca" sobie czyta.
Plus taki, że jak strzeli inna usługa to będzie miał te dane za darmo.

3. Przez zdarzenie (event) czyli message na kolejkę
Wg mnie tak powinno to być:
usługa "pytająca" produkuje nowe dane -> wypuszcza event z tymi danymi -> subskrybenci (w tym usługa "odpowiadająca") sobie je pobierają i zapisują do swoich wewnętrznych baz lub

CQRS: usługa "pytająca" produkuje nowe dane -> wypuszcza event z danymi -> usługa widokowa zapisuje sobie do bazy tego eventa -> usługa "odpowiadająca" pobiera sobie te dane z usługi widokowej
#programowanie #java

[Saly]

@mistyk-gehenny: usługa to serwis. Masło maślane, napisz jeszcze raz o co chodzi

[m.....y]

@Saly: zamienię na usługa pytająca i usługa odpowiadająca

[Saly]

@mistyk-gehenny: ale kto kogo pyta. Co to jest usługa odpowiadająca xd callback?

[m.....y]

@Saly: no usługa pytająca pyta usługę odpowiadającą

[try2fly]

@mistyk-gehenny: serwer może zwrócić do klienta dodatkowo id kursora, wtedy w następnym zapytaniu klient używa tego id żeby nawiązać do poprzedniego zapytania. Coś w stylu SCAN w Redisie

As you can see the SCAN return value is an array of two values: the first value is the new cursor to use in the next call, the second value is an array of elements.

[Kolorowezworki]

@mistyk-gehenny: HTTP. Nie rozumie tylko sytuacji, w której druga usługa pytająca pyta o to samo, a nie dostarcza danych. Bez sensu.

[PaaD]

@mistyk-gehenny: klasycznie: to zależy

zależy co to dane, jaki jest ich cykl życia itp, np. mogą po prostu paginować dane po REST, mogą subskrybować / streamingować dane przez Websockety/SSE, a jak siedzą w jakieś jednej sieci mogą pchać przez kolejki, bazy danych albo nawet pliki, no ale: to zależy ( ͡° ͜ʖ ͡°)

[Saly]

@mistyk-gehenny: jaki jest sens tego ping ponga? Na jakiej podstawie usługa B wie co usługa A ma jej dalej przekazać? Na pewno można wyrzucić bezpośrednie storowanie w kolejce, bo limity na rozmiar są zazwyczaj niskie.

[bst]

Co to znaczy ogromne? 1TB 1GB? Siec lokalna czy internety?

[m.....y]

@try2fly: no, ale to wolne będzie?

[m.....y]

@Kolorowezworki: no np. pytasz

.../images/pepe

to nie musisz znać koloru obramowania

a ten kolor obramowania może dostarczać inna usługa

nie chcesz pytać

.../images/pepe
body: { border: solid }

[m.....y]

@bst: np. 0,1 MB, podczas gdy normalne zapytanie ma 0,01 MB a requestów masz 500 na sekundę

[Saly]

@mistyk-gehenny: 0.1 MB to jest xd Wysyłaj normalnie

[m.....y]

@Saly: przy 500 requestach na sekundę też xd?

[m.....y]

@Saly: no i co z tym, gdy inna usługa bedzie ciała odpytać, to bedzie musiała zdobyć te dane

[Kolorowezworki]

@mistyk-gehenny: No to to powinny być osobne endpointy.

[MQs]

@mistyk-gehenny: Dane przekazywane pomiędzy usługami pytającymi a odpowiadającymi to jest dosłownie wszystko. Nawet ten komentarz.

[try2fly]

@mistyk-gehenny: a bo zamieszałeś z tym nazewnictwem "usługa pytająca" i "usługa odpowiadająca" :P to napisałem, że klient i serwer, a widzę, że chodzi o producera i consumera. No to tak, kolejka najlepsza.