[Wegrzynski]

#programowanie

Mirki, jak powinna wyglądać sekwencja komunikacji w MVC pomiędzy mikroserwisami, jeśli za pomocą GUI zmieniam konfigurację innego mikroserwisu B 3rd party (np. Node-red) za pośrednictwem swojego mikroserwisu A, który musi obrobić zapytanie przed wysłaniem do B?

1. GUI wysyła do mikroserwisu A wysyła zapytanie z nową konfiguracją.
2. Mikroserwis A zapisuje to zapytanie do swojej bazy danych, gdzie jest przechowywana konfiguracja B (Model w MVC).
3a. Mikroserwis A wysyła nową konfigurację do mikroserwisu B?
3b. Mikroserwis A pobiera nową konfigurację B ze swojej bazy danych
4b. Mikroserwis A wysyła nową konfigurację do mikroserwisu B?

Który scenariusz "a" czy "b" jest poprawny/lepszy? Czy może powinno być to zrobione jeszcze inaczej?

[Krolik]

Scenariusz a. Po co odczytywać z bazy coś co tam przed chwilą zapisałeś? Bezsensowne marnowanie cykli.

[kobrys13]

@Wegrzynski: Jeśli ogarniasz to przez GUI to ja nie widzę sensu zapisywania tego w serwisie A.

W mikroserwisach powinieneś mieć single source of truth, a tutaj duplikujesz dane.

Ja bym w trakcie obsługi requesta z GUI synchronicznie uderzał do B zapisując dane. Jak się nie uda to użytkownik od razu dostaje błędem.
Jest to dosyć atomowe.

A jak duże wolumeny to bym po prostu w serwisie A wrzucał to na kolejkę

[Wegrzynski]

@Krolik: @kobrys13 Czyli słusznie podejrzewałem że coś jest nie tak z tym pomysłem, bo tak jak napisaliście właśnie duplikuję dane - raz w bazie danych, a dwa w serwisie B (3rd party).

Tylko w związku z tym pytanie - jak GUI ma zapisywać/ odczytywać aktualną konfigurację B? Bezpośrednio z/do jego pliku konfiguracyjnego? Gdzie mają być przeliczane dane wysyłane z GUI do B?

Pytanie jest o tyle problematyczne, że w bezpośredni sposób

[kobrys13]

@Wegrzynski: Dobra - jak tak to opisałeś to nie wiem po co Ci serwis A, ale pewnie brakuje mi wiedzy domenowej.

Gdybym miał robić design serwisu na podstawie tego co napisałeś to najpierw bym to zdesignował asynchronicznie.

1. Event - konfiguracja/request -> to zapisujesz do bazy z jakims processing ID
2. Odczyt danych ze źródła (MODBUS) -> zapisujesz do storage raw response tego co odczytałeś z tym samym processing ID
3.

[Wegrzynski]

Jeśli Twoje GUI obsługuje asynchroniczne ładowanie/websockety lub mawet active pooling to nie potrzeba ci synchronicznego przeładowania strony czy wykonania requestu. Po prostu jak wynik będzie gotowy to go wyświetlisz na ekranie.

@kobrys13: GUI piszę w React. Generalnie podstawowy stack to MERN plus REDIS do cachowania.

Niestety, ale chyba to co opisałeś wydaje mi się zbyt skomplikowane jaka na mój poziom doświadczenia programistycznego xD I z tego powodu myślę że uproszę sprawę

[kobrys13]

@Wegrzynski: Własnie o tym pisałem i to miałem na myśli - nie baw się w dwa mikroserwisy tylko wsadź wszystko do jednego bo nie wygląda to w ogóle na dwie domeny żeby to trzeba bylo separowac dwoma serwisami.

Jak piszesz w React to tym bardziej nie ma problemu żeby poszczególne strony uderzaly sobie do web api wielu serwisów niezależnie.

Żadnej zasady nie lamiesz - do prostego projektu dokładnie bym tak zrobił.

[Wegrzynski]

@kobrys13: Dzięki wielkie za pomoc ( ͡° ͜ʖ ͡°)