Komunikacja front/backend z mikroserwisami (RabbitMQ) |
Komunikacja front/backend z mikroserwisami (RabbitMQ) |
19.07.2022, 20:54:25
Post
#1
|
|
Grupa: Zarejestrowani Postów: 44 Pomógł: 5 Dołączył: 20.05.2019 Ostrzeżenie: (0%) |
Szukam informacji na temat komunikacji front/backend w mikroserwisach opartych o RabbitMQ, ale niestety bezskutecznie.
Załóżmy, że mam prostą strukturę: - Front - API Gateway - Mikroserwisy: A, B, C które komunikują się asynchronicznie przy użyciu Rabbita. Jak powinna wyglądać komunikacja Frontu z Backendem w przypadku potrzeby pobrania listy w postaci kompozycji danych z mikroserwisu A i B? Front powinien komunikować się w takiej sytuacji z API Gateway, a API Gateway synchronicznie pobierać dane z danego mikroserwisu poprzez wewnętrzne requesty? Czy może lepiej zrezygnować zupełnie z API Gateway i komunikować się bezpośrednio z danym mikroserwisem? Myślałem też, że można by zrobić jakiś agregat do odczytu, który miałby dane wszystkich mikroserwisów i byłyby synchronizowany poprzez Rabbita z mikroserwisami. Wtedy komunikacja w przypadku takich synchronicznych requestów byłaby Front <-> API Gateway <-> Agregat Dobrze myślę, czy to zupełnie inaczej powinno wyglądać? Nikt, nic? Zły dział? Myślałem, że ktoś coś podpowie :-) |
|
|
20.07.2022, 13:45:37
Post
#2
|
|
Grupa: Zarejestrowani Postów: 343 Pomógł: 70 Dołączył: 15.07.2014 Ostrzeżenie: (0%) |
Powinieneś mieć strukturę:
Front <> API <> Services Front pyta API - może być asynchronicznie, wtedy nie będzie widać aż takich opóźnień w aplikacji - a to co dzieje się już po poziomie API i Services, jak się oni komunikują między sobą, etc. to już jest inna "bajka". Możesz zrobić wszedzie async jak chcesz. Tylko pamiętać musisz, że nigdy nie dostaniesz odpowiedzi "natychmiast". Pomiędzy frontem a API możesz też postawić Redisa i cache'ować powtarzające się zapytania, to będzie kolejne usprawnienie, ale dopiero jak zauważysz problemy z wczytywaniem się contentu. |
|
|
Wersja Lo-Fi | Aktualny czas: 25.04.2024 - 00:46 |