Problemy wynikajcie z architektury mikroserwisów #programowanie
Po obejrzeniu kursu DShop mam pewną zagwozdkę.
Przykładowo mamy dwa mikroserwisy Customer oraz Orders zgodnie z wskazówkami z kursu OrdersDb przetrzymuje tylko minimalną ilość informacji o danym Customer - w DShop był to tylko klucz po którym pobierano z mikroserwisu Customer pełne informacje, jeśli były potrzebne.
Co w przypadku gdy mikroservice Orders udostępnia metodę "datatable" (paginacja, sortowanie itp) ale potrzebuje pełnych informacji o Customer (a mamy w bazie OrdersDB tylko klucz CustomerID)? Wydaje się być to nierozsądne wywołać np 20 x GET z CustomerApi aby dalej doincludować te dane do Orders ?
Sytuacja się komplikuje jeszcze bardziej gdybyśmy chcieli wykona sortowanie np po Customer.FirstName.
@mrKuaku: Problem na tyle dziwny, że mam wrażenie, że coś jest nie tak zaprojektowane. Przekazujesz tablicę cusomerId w jednym requeście i serwis datatable powinien sam wybrać zamówienia i dołączyć dane użytkowników. Taka fragmentacja jak piszesz jest oczywiście zupełnie bez sensu, może nawet zastosowanie tutaj mikroserwisów jest nieoptymalne. To, że coś się sprawdza w jednym rozwiązaniach, niekoniecznie musi w innych. Uważałbym z traktowaniem tutoriali jako przepisów na aplikację, bo często pasują jedynie
Po obejrzeniu kursu DShop mam pewną zagwozdkę.
Przykładowo mamy dwa mikroserwisy Customer oraz Orders
zgodnie z wskazówkami z kursu OrdersDb przetrzymuje tylko minimalną ilość informacji o danym Customer - w DShop był to tylko klucz po którym pobierano z mikroserwisu Customer pełne informacje, jeśli były potrzebne.
Co w przypadku gdy mikroservice Orders udostępnia metodę "datatable" (paginacja, sortowanie itp) ale potrzebuje pełnych informacji o Customer (a mamy w bazie OrdersDB tylko klucz CustomerID)? Wydaje się być to nierozsądne wywołać np 20 x GET z CustomerApi aby dalej doincludować te dane do Orders ?
Sytuacja się komplikuje jeszcze bardziej gdybyśmy chcieli wykona sortowanie np po Customer.FirstName.