Aktywne Wpisy

lubie-sernik +208
W moim budynku pracuje taka laska z krótkimi włosami co się bardzo do mnie uśmiecha. Inne też się czasem uśmiechną ale ta wyjątkowo bardzo się uśmiecha.
W każdym razie dziś się jej bardziej przyjrzałem i wydaje mi się, że to jest jednak chłop.
Ta #tajlandia to jedna wielka pułapka.
Na
W każdym razie dziś się jej bardziej przyjrzałem i wydaje mi się, że to jest jednak chłop.
Ta #tajlandia to jedna wielka pułapka.
Na
nowszyja +1179
Zwycięzca Grand Press Photo 2026 znany! Zdjęcie przestawia polskiego lekarza, który odpoczywa po operacji drenowania budżetu Szpitala Południowego w Warszawie.
#lekarz #lekarski #konowalposting #afera #lekarz100k #heheszki
#lekarz #lekarski #konowalposting #afera #lekarz100k #heheszki
źródło: HLA1ckFWQAAw6Fo
Pobierz


![Moja mama mogła żyć, ale nie było dla niej miejsca [na OIMIE]](https://wykop.pl/cdn/c3397993/d58140d2e77085c69d1acf192736e4f5aa8a2f3cd44b5a6317588b87f12d3322,q80.webp)

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 ( ͡° ͜ʖ ͡°)
źródło: modbus-wykop
Pobierz@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.
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
@tylko_zerknalem: SQL-a miałem na studiach i czułem podskórnie że coś jest nie tak