Mirki jak powinna wyglądać prawidłowo napisana infrastruktura backendowa? Załóżmy ze mam sobie aplikacje składająca się z 30 mikroserwisów i jeden serwis frontendowy. Jak powinna wyglądać prawidłowa komunikacja pomiedzy backendem i frontendem?
1. Frontend powinien komunikować się z 1 serwisem backendowym a ten dalej rozsyłać requesty na poszczególne serwisy
2. Frontend uderza prosto do poszczególnych serwisów
@Divgh: to pewnie najlepiej jakiś gateway/ingress, który przekieruje zapytanie do odpowiedniego backendu. Wszystko ma ta samą domenę tylko w zależności od path trafia gdzie indziej
@James456: czyli np. jakis load balancer na dockerze i jedno główne api, które rozsyla zapytania na poszczególne serwisy po udanej autoryzacji? Ale w takim razie czy główne api gateway nie bedzie się zapychać pod ilością zapytań? No chyba, że uruchomić to w kilku instancjach w docker swarmie, ale czy takie podejscie jest dobre?
@LazyInitializationException: w 87% przypadków (instytut danych z dupy) jest to po prostu monolit #!$%@? na 30 repozytoriów, z architekturą mikroserwisów nie mający nic wspólnego.
@Divgh: API gateway kieruje ruchem do poszczególnych API mikroserwisow, nie wykonuje żadnej logiki, logika wykonywana jest dopiero w samodzielnych mikroserwisach (np autoryzacja, logika biznesowa)
@Divgh: Moim zdaniem jak robisz mikroserwisy, to po co ten punkt wejścia, mija się rób celem No chyba, ze warstwa prezentach danych do frontendu nie jest mocno wymagająca, a mikroserwisy robią jakaś zaawansowana logikę biznesowa.
Jak powinna wyglądać prawidłowa komunikacja pomiedzy backendem i frontendem?
1. Frontend powinien komunikować się z 1 serwisem backendowym a ten dalej rozsyłać requesty na poszczególne serwisy
2. Frontend uderza prosto do poszczególnych serwisów
#programowanie
@Divgh: najpierw rozwiązałbym ten problem.
Komentarz usunięty przez moderatora
@LazyInitializationException: w 87% przypadków (instytut danych z dupy) jest to po prostu monolit #!$%@? na 30 repozytoriów, z architekturą mikroserwisów nie mający nic wspólnego.