Ez a tipikus esete annak, amikor az ember választ a projekt elején technológiát meg architektúrát, az aktuális tudása meg az állapotok alapján, aztán menet közben derülnek ki dolgok.
Pl. amióta nézem ezt a projektedet, azóta nem értem a vastag klienst meg a Qt-t. Meg persze az architektúrát sem, de nyilván ebben az is vastagon benne van nálam, hogy én részt vettem 15-20+ éve egy bizonyos típusú hálózati eszközöket menedzselő szoftverprojektben, és még emlékszem, hogy milyen döntéseket kellett meghozni, és mik voltak a szempontok, és aztán miből lett később gond és mi volt baromi jó választásunk.
Szóval ha ma megkérdeznél, hogy milyen stackre csinálnék hálózati monitorozást, az tuti, hogy a következő technológiák nem lennének benne:
- vastag kliens (vs webböngésző), vagy ha mindenképpen kell valami vastagkliensszerűség akkor az biztosan egy standard webböngésző motorra épülne
- Windows bármi másra, mint megjelenítésre, ami ugye az előző alapján egy szál web böngésző (vagy a motorjára épülő valami) lenne
- net-snmp (anno 2 hónapig néztük, hogy mit lehetne ezzel kezdeni, aztán újraimplementáltam a nekünk kellő részeket egy hét alatt - pár képernyőnyi kód volt az a kód, ami kellett belőle, a MIB parser volt az egyetlen, amit meghagytunk as-is)
- a gyűjtött adatok RBDMS sorokban egyesével tárolva (baromira drága I/O-ban, nem skálázódik értelmesen)
- monolit, single-machine, böhöm izék (vs elosztott, skálázható, microservice-alapú architektúra, újrahasznosítva a mások által megírt open-source dolgokat: Prometheus, Grafana, és haverjaik)
- (le)fordított nyelvben megírt komplett cucc (vs moduláris, script típusú nyelvben custom kóddal bővíhető architektúra)