Microservice, REST API jak to ugryźć?

Dobry!
Na wstepie zaznacze, że wypadlem z webu wieki temu i nie bardzo wiem jak sie wstrzelic w ten temat. Moze to juz dluzsza chwile ale gdzie nie spojrze wszyscy piszą aplikacje oparte o 'microservices' i wystawiaja 'rest api'. Ktos mi wyjaśni po ludzku o co tu do cholery chodzi? Jak jeszcze pisałem kiedyś aplikację (akurat wtedy w ASP/C#) to robiłem sobie 3 katalogi (MVC) do których pakowalem co potrzeba. Front w katalogu Widoku i tyle.
A dzis zabieram sie za robote i nie wiem od czego zaczac. Widze ludzi piszacych jakies API do ktoego podpinaja front (nie mam za bardzo pojecia jak to ugryzc) albo aplikacje oparte na microservices co tez niewiele mi mowi...
Ktos litosciwy zechce skrobnac kilka zdan tak zeby moc zrozumiec jak sie dzisiaj do tego zabrac najprosciej? :-)

*Tak, wiem jak dziala protokol http ale nadal srednio rozumiem cala te idee...

To może napisz co chcesz zrobić, skoro

dzis zabieram sie za robote i nie wiem od czego zaczac.

będzie łatwiej wytłumaczyć na realnym przykładzie.

Na realnym przykładzie? Hmmm. Chciałem odświeżyć sobie wiedzę i zobaczyć jak się teraz buduje ale może metodą pytań do czegoś dojdziemy. A więc tak. Trafiłem na taki artykuł żeby w ogóle zrozumieć czym są te cudowne mikroserwisy
dariuszkoncewicz.pl/mikroserwisy-mocne-i-slabe-strony/

Zakładam, że jest on w miarę treściwy i wyjaśniający podstawy.

Zasadniczo, architektura mikroserwisów jest sposobem opracowywania oprogramowania, jako zestawu niezależnie rozmieszczonych, małych, modularnych i luźno powiązanych usług, gdzie każda usługa wykonuje unikalny proces lub jego fragment i komunikuje się z resztą rozwiązania poprzez dobrze zdefiniowany, lekki mechanizm.

Blablabla. Powiedzmy zatem, że mam jakąś małą aplikację. Przyjmijmy, że mamy w niej kilka modułów:

• Rejestracja
• Logowanie
• Dodawanie wpisów (każdy wpis ma tytuł, skrócony opis, pełną treść, datę)
• Kategorie

Niech to będzie jakiś prosty mini blog. Klasycznie pisząc takie coś X lat temu zrobilibyśmy to mniej więcej tak:
Mamy Controller, Model, View - gdzie jak chcę dodać przykładowo nowy moduł galerii to piszę logikę w Modelu, Controllerem odbieram dane, a w widoku układam jak to ma wyglądać.

Idąc zgodnie z logiką tego co przeczytałem wyżej o mikroserwisach powinienem napisać osobny serwis do każdej z tych usług po czym do każdego wystawić API? I ma być bonusowo jakiś 5ty element, który tym wszystkim zarządza (jak pierścień we Władcy Pierścieni)? Czy one mają komunikować się między sobą? Tu też istnieje jakiś podział struktury projektu?
A jak dorzucić do tego front-end? Przyznam szczerze, że przeczytałem już kilka wpisów o mikroserwisach i im dalej to czytam tym wiem mniej.
Rozumiem, że to jest takie fajne bo mogę w locie wrzucać nowe funkcjonalności, tak? Mogę jakąś usługę wyłączyć/zastąpić drugą nowszą/lepszą/przydatną w danej chwili? O rany...chyba się pogubiłem. Jest coś napisanego z ładem i składem na temat tych nowoczesnych restów, usług, mielenia jsonów i tym podobnych? :-D
Wyjście z desktopa wygląda boleśnie.

Z API chodzi o to, że masz oddzielną aplikację do backendu, która przyjmuje i zwraca JSONy (tzn. może być XML, albo pewnie i INI, ale JSON teraz najpopularniejszy). A frontend to oddzielna aplikacja. Jeśli mówimy o webie, to teraz jest milion frameworków oraz bibliotek JS do robienia frontendowych aplikacji, takich jak Angular czy React.
Spora różnica w porównaniu z ASP.NET MVC, w którym backend i frontend był w jednej aplikacji.

Z REST chodzi o to, że zamiast jakiegoś web procedure call, czyli HTTP POST do każdej akcji i URLe wstylu: api.com/updateCustomerData, api.com/orderProducts, api.com/getTransactions masz URLe unikalnie wskazujące zasoby, a użycie odpowiedniego HTTP verb mówi czy pobieramy/dodajemy/edytujemy/usuwamy dane. Dlatego masz: GET, POST, PUT, DELETE, a przykładowe URLe w wersji restowej to będą: PUT api.com/customers i POST api.com/customers/{customerId}/transactions/, GET api.com/customers/{customerId}/transactions/. Jak widzisz - składanie zamówienia i przeglądanie historii zamówień ma tutaj ten sam URL, ale różne HTTP verb.
(To takie dość mocne uproszczenie, w końcu trudno jednym zdaniem streścić czyjąś dysertację doktorską.)

Z mikroserwisami chodzi o to, że zamiast tworzyć ogromny system, który ma wiele modułów odpowiedzialnych za różne aspekty całego biznesu, każdym aspektem zajmuje się oddzielny, "mały" serwis. Oddzielnymi mikroserwisami mogą być np.: zarządzanie kontami użytkowników, rejestracja zamówień, przetwarzanie płatności, uwierzytelnianie. To są logicznie oddzielne koncepcje, zaś jeśli chodzi o architekturę to mogą korzystać z kompletnie różnych źródeł danych, integrować się z innymi serwisami zewnętrznymi, więc jest sens je wydzielać jako oddzielne podsystemy.

A blog to nie jest po prostu coś, co da się zrobić sensownie korzystając z mikroserwisów - masz tam tylko jeden kontekt, obiekty biznesowe są ze sobą mocno powiązane. Nie tędy droga.

Uważam że nie ma potrzeby korzystania z microserwisów jak nie ma potrzeby i uczenia się ich na siłe, bo jak już są potrzebne to większych systemach ;) .

scibi92 napisał(a):

Uważam że nie ma potrzeby korzystania z microserwisów jak nie ma potrzeby i uczenia się ich na siłe, bo jak już są potrzebne to większych systemach ;) .

Zapewne tak jest ale gdy nie jesteś obecny w danym miejscu 4-5 lat po czym patrzysz co i jak się teraz robi i nagle w głowie duże wtf...

A blog to nie jest po prostu coś, co da się zrobić sensownie korzystając z mikroserwisów - masz tam tylko jeden kontekt, obiekty biznesowe są ze sobą mocno powiązane. Nie tędy droga.

Pierwszy lepszy przykład, który mi się nasunął do głowy. Dzięki za sensowne wyjaśnienie. Dokopię się dalej już samemu.

Microservice na papierze wygląda fajnie. Ale gdy system opiera się na kilku, kilkunastu takich serwisach problemów jest masa - jest wręcz odwrotnie proporcjonalna do ilości serwisów. Wersjonowanie, zależności, utrzymanie, testowanie, debugowanie. Straszne... jak w życiu :D

Slepiec napisał(a):

Microservice na papierze wygląda fajnie. Ale gdy system opiera się na kilku, kilkunastu takich serwisach problemów jest masa - jest wręcz odwrotnie proporcjonalna do ilości serwisów. Wersjonowanie, zależności, utrzymanie, testowanie, debugowanie. Straszne... jak w życiu :D

Problemy są takie, że jest więcej konfiguracji, infrastruktury i zarządzania nimi, ale to wszystko można automatyzować. Oczywiście to jest koszt, którego nie ma sensu ponosić w małych projektach.

Ale za to system jako całość jest bardziej stabilny (bo jeśli coś nie działa, to są to pewne elementy, całość na raz sama raczej nie padnie), łatwiejszy w testowaniu (bo każdy team testuje swoje moduły, nie trzeba mieć całości systemu u siebie zainstalowanej i skonfigurowanej, żeby pracować), łatwiej też o continous deployment jeśli mamy mikroserwisy, a dzięki temu szybciej dowiadujemy się o błędach oraz nie mamy przestojów w pracy na tygodniowe merge.