Wpis z mikrobloga

Projektuję prostą aplikację (do nauki, bez skomplikowanej logiki biznesowej), którą chcę oprzeć o mikroserwisy. Logowanie i zakup produktów w oparcie o cenę pobieraną z zewnętrznego API.

Mam mikroserwis od konta użytkowników, a także mikroserwis od produktu wraz z ceną. Jak zapisywać jakie produkty posiada użytkownik? W monolicie robię sobie po prostu relację users_products, a w mikroserwisach przy tym całym rozdziale jak to powinienem zaprojektować?

Kolega sugerował zrobić monolit do którego dorabiam moduły w mikroserwisach, ale to chyba nie na tym polega projektowanie aplikacji w oparciu o mikroserwisy?

#programowanie #mirkoserwisy #webdev #naukaprogramowania #php
  • 10
Mam mikroserwis od konta użytkowników, a także mikroserwis od produktu wraz z ceną. Jak zapisywać jakie produkty posiada użytkownik? W monolicie robię sobie po prostu relację users_products, a w mikroserwisach przy tym całym rozdziale jak to powinienem zaprojektować?


@Jurix: jeśli masz takie problemy to właśnie oznacza, że taka aplikacja nie powinna być na mikroserwisach.
@spaduwa_mam_robote: Wrzucam na z czarno tylko politycznych trolli (z obu stron) oraz atencjuszy/ki, więc do którego z tych grup musiał się załapać.

@nowiutki: Czyli takiego np. CMS'a nie da się zrobić na mikroserwisach? To dlaczego tak często porównuje się zalety i wady mikroserwisów vs monolit, mówi że mikroserwisy łatwiejsze w utrzymaniu przy starszej aplikacji, przy dużych zespołach, jeśli niektórych, podstawowych rzeczy nie da się zrobić w tej architekturze?
via Wykop Mobilny (Android)
  • 2
@Jurix: da się zrobić bez problemu, łączysz je ze sobą przez id użytkownika czy co tam chcesz, kwestia tego, że rzadko kiedy potrzebujesz zebrać i dane usera i dane produktów w tej samej chwili. Z reguły przed mikroserwisami stawiasz sobie api gateway które ci zbiera co potrzebujesz z mikroserwisow. Łączysz je dokładnie tak jak w przypadkiem monolitu, tylko query do db nie robisz jako inner joiny itd tylko Calle do różnych
via Wykop Mobilny (Android)
  • 1
@Jurix: tak najprościej, najczęściej jak wspominałem masz jakieś api gateway przed nimi, mikroserwisy masz w prywatnych subnetach i dajesz requesty do gatewaya żeby nie pamiętać miliona endpointsow i najlepiej jak już lecisz w mikroserwisy to robić je na dockerze, k8s lub czymś vo się łatwo i szybko skaluje, wtedy samoistnie skaluje się tylko ten mikroserwis który ma większy traffic zamiast całość apki
@Jurix zrób na razie dobry modularny monolit. Jak dobrze podzielisz go na moduły i wyznaczysz odpowiednie granice architektoniczne to nie będzie problemu przenieść taki moduł jaki mikroserwis. Poczytaj o granicach architektonicznych oraz jak je przekraczać. Polecam książkę "czysta architektura" wujka boba
@Jurix: ja bym zrobił serwis, który odpowiada za zbieranie informacji o produktach użytkownika. Odpytujesz go wtedy o wszelkie relacja tych dwóch encji. Mikroserwis nie musi wiedzieć nic ponadto i mieć dostępu do encji. Klient tego API będzie miał logikę, która na podstawie zwróconego przez mikroserwis zbioru określi jak wykorzystać i interpretować te dane.

mówi że mikroserwisy łatwiejsze w utrzymaniu przy starszej aplikacji, przy dużych zespołach, jeśli niektórych, podstawowych rzeczy nie da
@Jurix ja stworzyłbym dwa produkty, jeden w kontekście bazy produktów, drugi w kontekście użytkownika (mam na myśli zakupione produkty). Jeśli chodzi o produkty danego użytkownika w kontekście bazy produktów, to wystarczy tutaj id użytkownika na produkcie. Więc przy strzale do serwisu z produktami bez problemu pobierzesz produkty zautoryzowanego użytkownika.