Wpis z mikrobloga

#programowanie #nodejs #programujzwykopem

W ramach nauki i zabawy za cel wziąłem sobie zrobienie apki MERN do zarządzania klientem ModbusTCP postawionym na Node-RED (środowisko low-code), która to by robiła za CRUD-a do tego klienta - ładowanie i zmiana konfiguracji zmiennych oraz ich wyświetlanie. Wraz z postępem umiejętności zastanawiam się nad architekturą, którą chcę oprzeć na mikroserwisach i MVC.

Gdzie powinna być przechowywana konfiguracja tego klienta Modbusa TCP? Czy architektura z obrazka jest przekombinowana?

Ja sobie założyłem architekturę jak na obrazku i w przypadku zmiany konfiguracji (np. wgranie listy zmiennych z pliku) sekwencja komunikatów wygląda następująco:
1. Frontend wysyła frontendową listę do Managera
2. Manager wysyła do MongoDB listę w formacie frontendowym
3. Manager to przetwarza do NodeRedowego formatu i zapisuje do MongoDB
4. Manager pobiera NodeRedową konfigurację z MongoDB
5. Manager wysyła konfigurację do Node-RED

Chodziło o to żeby rozbić odpowiedzialności na mikroserwisy, bo teoretycznie Frontend mógłby gadać bezpośrednio z Node-REDem i by działało, ale ja chciałem to zrobić profesjonalnie po mikroserwisowemu ( ͡° ͜ʖ ͡°) Czyli:
- Jak Frontend chce pobrać aktualną konfigurację, to ją pobiera od Managera w gotoweej formie
- Jak restartujemy system to mamy pewność że konfiguracja jest spójna bo ją ładujemy na zasadzie pobrania z MongoDB frontendowego formatu, przetworzenia do Node Red i wysłania do Node-REDa i Mongo
itd.

Dobrze myślę czy przekombinowałem? ( ͡° ͜ʖ ͡°) Jak wystarczy zapału i sił to mają się pojawiać kolejne mikroserwisy (np. OPC) które nie muszą się opierać na Node-RED i chcę żeby architektura wyglądała na docelową ( ͡° ͜ʖ ͡°)

Dla czytelności nie dodałem Redisa jako brokera ( ͡° ͜ʖ ͡°)
Wegrzynski - #programowanie #nodejs #programujzwykopem

W ramach nauki i zabawy za ce...

źródło: modbus-wykop

Pobierz
  • 4
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

  • 0
Z ciekawości: czemu Mongo jako storage i jaką dokładnie rolę pełni tutaj Redis?


@tylko_zerknalem: Mongo - bo NoSQL, jest popularny, szybki, oparty na dokumentach i nadaje się do ogólnych zastosowań.

Redis ma pełnić rolę brokera w schemacie pub/sub oraz do kolejkowania wiadomości.
  • Odpowiedz
@Wegrzynski:

Mongo - bo NoSQL, jest popularny, szybki, oparty na dokumentach i nadaje się do ogólnych zastosowań.

Jeżeli chcesz użyć jakiejś bazy NoSQL i zobaczyć z czym to się je, to oczywiście takie podejście ma sens. Natomiast w ogólności jest stosunkowo mało use-case'ów gdzie wybór Mongo zamiast np. Postgresa będzie uzasadniony. Wszystkie cechy które wymieniłeś (poza byciem NoSQL) można w pełni do niego zaaplikować (włącznie z przetwarzaniem dokumentów, ponieważ Postgres
  • Odpowiedz
  • 0
Jeżeli chcesz użyć jakiejś bazy NoSQL i zobaczyć z czym to się je, to oczywiście takie podejście ma sens. Natomiast w ogólności jest stosunkowo mało use-case'ów gdzie wybór Mongo zamiast np. Postgresa będzie uzasadniony. Wszystkie cechy które wymieniłeś (poza byciem NoSQL) można w pełni do niego zaaplikować (włącznie z przetwarzaniem dokumentów, ponieważ Postgres ma dedykowane typy dla JSON-ów).


@tylko_zerknalem: SQL-a miałem na studiach i czułem podskórnie że coś jest nie tak
  • Odpowiedz