Návrh frontend/backend model-view-controller

[Marekuss]

Ahojte.

Mame napisanu GUI aplikaciu v QT, ktora sa stara o zobrazovanie dat zo snimacov a zobrazuje ich na paneli (1024/768), coz funguje pekne a dobre. Ovsem, casto sa stava ze zakaznik chce zmenit design, navrh toho GUI na ine farbicky, poposuvat zopar okien a pod, takze sa to musi menit v QT, znova skompilovat, odtestovat a dodat...

Kedze nam doba HW poskocila, tak premyslame o tom, ze by sa dalsia verzia toho GUI prerobila do electronu, pripadne cisto na chromium s HTML, CSS, javascript. Na Paneli by bezal chromium, v nom by bolo navrhnute GUI a data by tahal v nejakom definovanom formate zo siete.

Otazka do plena, ak to postavime na chromium, je dobre do toho designu zapracovat MVC, alebo riesit cisto iba "View" a zvysok nechat na backende na serveri? Alebo napisat cele MVC v javascripte/typescripte a data pollovat zo serveru?
A do tretice, pozeral som po websockets, trochu sa mi zapacilo, bude to vhodne?

Diky

[Reklama]

[Ondrej Nemecek]

Ahojte.

Mame napisanu GUI aplikaciu v QT, ktora sa stara o zobrazovanie dat zo snimacov a zobrazuje ich na paneli (1024/768), coz funguje pekne a dobre. Ovsem, casto sa stava ze zakaznik chce zmenit design, navrh toho GUI na ine farbicky, poposuvat zopar okien a pod, takze sa to musi menit v QT, znova skompilovat, odtestovat a dodat...

Kedze nam doba HW poskocila, tak premyslame o tom, ze by sa dalsia verzia toho GUI prerobila do electronu, pripadne cisto na chromium s HTML, CSS, javascript. Na Paneli by bezal chromium, v nom by bolo navrhnute GUI a data by tahal v nejakom definovanom formate zo siete.

Otazka do plena, ak to postavime na chromium, je dobre do toho designu zapracovat MVC, alebo riesit cisto iba "View" a zvysok nechat na backende na serveri? Alebo napisat cele MVC v javascripte/typescripte a data pollovat zo serveru?
A do tretice, pozeral som po websockets, trochu sa mi zapacilo, bude to vhodne?

Diky

Přepisem do neznámé technologie si podle mě nepomůžete. Protože pokud nemáte aplikaci napsanou pořádně v QT, tak budete plavat i v jiné technologii. A naopak, pokud ji pořádně napsanou už máte, neměli byste mít problém s drobnými úpravami a nasazením (používáte QML?). Tolik můj odhad.

[Kit]

Otazka do plena, ak to postavime na chromium, je dobre do toho designu zapracovat MVC, alebo riesit cisto iba "View" a zvysok nechat na backende na serveri? Alebo napisat cele MVC v javascripte/typescripte a data pollovat zo serveru?
A do tretice, pozeral som po websockets, trochu sa mi zapacilo, bude to vhodne?

Nejjednodušší to bude přes ajax, websocket by neměl žádnou výhodu. Klient si stáhne data ze serveru, nejlépe v JSON. Následně je nějaká javascriptová knihovna převede do žádané grafické podoby a zobrazí.

[L..]

Jelikož tam bude jedno view a jedna/dvě operace (úvodní load / refresh), tak se nějak moc patlat s MVC nemá IMHO smysl.

Nicméně si nemyslím, že byste si změnou technologie nějak výrazně pomohli, co se týče customizovatelnosti. Customizovatelné třeba na základě konfiguračního souboru se dá udělat i to Qt. Maximálně že by si to zákazník mohl sám přestylovat pomocí nějakého pluginu do prohlížeče co umí vnutit stránce styl, ale to nepředpokládám, že by byla cesta schůdná pro větší počet firem.

[registrovany_ava]

Já dělám něco podobného, měřicí aplikaci co sbírá data z různých snímačů, něco nad nimi počítá, ukládá je na disk, celé se to v realtime někde ukazuje, měření se dá spustit s nějakými parametry a ukončit.

Aplikace je rozdělená na dvě nezávislé části jako klient/server, na GUI(klient) a něco co interně nazýváme "jádro"(server). Jádro se stará o samotné spouštění/ukončování měření, vyčítání zpracování ukládání dat.

GUI a jádro spolu komunikují výhradně po TCP zprávami zabalenými do Protocol buffers (dnes bych asi použil FlatBuffers). Konkrétní podoba zpráv je na tom skoro to nejdůležitější, vlastně ti určuje celou architekturu aplikace. Při návrhu zpráv se držíme zhruba těchto zásad:

 - Veškerá komunikace je Request(GUI) - Response(jádro)
 - GUI je možné kdykoliv ukončit a později znovu spustit, případně je dokonce možné mít připojených víc GUI najednou, aniž by to nějak ovlivnilo běh jádra. Když se GUI pustí později, dovede od jádra vyčíst stav a ukázat příslušné ovládaci a zobrazovací prvky.
 - jádro a GUI spolu nemohou komunikovat nijak jinak, tj. GUI má např. zakázané hrabat do uložených datových nebo konfiguračních souborů. Tím je mj. možné mít obojí puštěné na různých počítačích.

 V praxi je implementován request "Jádro, v jakém jsi stavu", to odpoví něco jako "připraven měřit, spouštím měření, měřím, ukončuji měření, ..". GUI se na stav periodicky ptá, protože se kdykoliv může přihodit, že nějaká externí událost (selhání měření, jiný klient) stav změní.

 Dále je implementován request "Jádro, pošli (poslední) odměřená data", který dává smysl jen ve stavu "měří se".

 Dále jsou implementovány povely jako "spusť měření, ukonči měření" atp. Důležité je, že OK odpověď od jádra neznamená "OK, spustil jsem měření", ale "OK, přijal jsem povel ke spuštění měření". GUI nesmí po přijetí kladné odpovědi na spuštění měření předpokládat, že měření skutečně běží a třeba změnit obrazovku, to dělá pouze v reakci na request "Jádro, v jakém jsi stavu".

Je toho samozřejmě mnohem víc, ale tohle je ten důležitý základ.


Tenhle přístup se nám dost vyplatil, během let jsme dokonce postupně úplně přepsali GUI (Scala -> C#) i jádro (C++ -> Rust), a nové GUI nám funguje se starým jádrem a naopak, to bylo dost praktické. Striktní oddělení a protokol jasně definují zodpovědnosti.

V principu by, abych se obloukem vrátil k původní otázce, klidně bylo možné udělat GUI klienta jako webovou aplikaci. Jestli máte prostor pro experimentování, určitě zauvažujte nad použitím jazyka Elm.

[Reklama]

[Standa Blábol]

Jak tady ctu, vymyslet se da ledacos.

Osobne bych v danem pripade sel do backend frameworku, napr Spring Boot, co veskera data a RPC vystavi jako REST/JSON.

A klientbprosty www browser s javascript frameworkem, ktery bude JSOny konzumovat.

Na www.primefaces.org je pekny balik widgety pro angular, vue a react.
A i pro JSF2, pokud JSON nevyhovuje.

[hurvajs spejbl]

použité technologie záleží na tom, co od GUI čekáte... Těžko rozebítal. Osobně bych se Electronu vyhnul, dělal jsem v něm a bylo to docela peklo. Výhodou pak ale zase je cross-platform "desktop" aplikace.

Záleží i jaké máte preference. Pokud je projekt funkční a potřebuje vyloženě refaktoring, nebo máte čas či peníze od klienta na přepsání, uvažoval bych klidně i o novém technologii (.NET Core / Java apod) s nějakým FE částí, ať už Reactem či čistým Vanilla JS. Ale pokud to u vás nikdo neumí, tak bych zůstal u QT, rozhodně jde rozšířit.

REST API je samozřejmost, pokud budete dělat nový BE. Dávají smysl i sokety. Záleží na požadavcích, jak jsem psal

[luvar]

Ak správne chápem, rady smerujú prevažne k pool metóde. Teda, že GUI (v JS, html) si má dáta periodicky pýtať. Ja by som odporúčal opačný smer. Dáta by mali byť (ak sú realtime) posielané proaktívne z backend-u. Teda využitie websoketov. Dá sa tým riešiť mnoho vecí (aj také, ktoré http2 už rieši, napr multiplexing, asynchronicita). Ak by váš framework pre backend nepodporoval websokety (predsalen kúsok neštandard a ak je po ceste reverzné proxy, tiež to treba nastaviť), tak by som sa pozrel na veci ako HTTP Streaming, HTTP Long Polling, či SSE (server side events).

Je pravda, že websokety má naozaj zmysel použiť zvačša pri veciach ako obnova kurzov na stránke stávkovej kancelárie, kde ten stream mení desiatky číselok za sekundu (mrknite https://www.williamhill.com/, či niečo lokálne, napr https://www.nike.sk/live#/prehlad, zobrazte si devel konzolu, network časť a tam typ requestov WS (web sockets). Vo firefoxe je tam niečo ako "messages" a vidno, čo server tlačí.

V rôznych technológiách sú rôzne výhody/nevýhhody ale hralvé rozdiely sú latencia, overhead na správu a kompatibility (vpodstate dnes už OK).

[Zabanovaný Anonymní Troll]

A co se vam jako nelibi na tom novejsim Qt GUI frameworku? Nemam ted namysli ten starsi co vypada jak Winforms, ale ten novejsi kde se vsechno modeluje ze ctvercu - co vam jako na tom nevhyvouje, to nechapu.

Jinak pokud ten UI bude bezet na stejne masine nebo siti jako backend, tak jednoznacne doporucuju pouzit Server-side rendering + a na dynamicky obsah JQuery. Co ma v repertoaru C++ na server side render nevim. Eventualne kdyby server side v C++ stal za pikacu, tak muzete pouzit Mustache - to v principu funguje velice podobne jako server side rendering, akorat se to odehrava na frontendu a na backendu vam staci mit k tomu rest. Vyhoda oproti React.js je, ze je to mnohem jednodussi. A kdyz tak nad tim premyslim, tak Mustache bude i pro C++, takze uz vite co muzete pouzit i na ten server side.

[gill]

A co se vam jako nelibi na tom novejsim Qt GUI frameworku? Nemam ted namysli ten starsi co vypada jak Winforms, ale ten novejsi kde se vsechno modeluje ze ctvercu - co vam jako na tom nevhyvouje, to nechapu.

Jinak pokud ten UI bude bezet na stejne masine nebo siti jako backend, tak jednoznacne doporucuju pouzit Server-side rendering + a na dynamicky obsah JQuery. Co ma v repertoaru C++ na server side render nevim. Eventualne kdyby server side v C++ stal za pikacu, tak muzete pouzit Mustache - to v principu funguje velice podobne jako server side rendering, akorat se to odehrava na frontendu a na backendu vam staci mit k tomu rest. Vyhoda oproti React.js je, ze je to mnohem jednodussi. A kdyz tak nad tim premyslim, tak Mustache bude i pro C++, takze uz vite co muzete pouzit i na ten server side.

jasná nevýhoda Mustache oproti React a Vue je překreslování celé šablony při každé změně. Na průběžné změny nepřijatelně pomalé, nepoužitelné. První render můžete provést i na serveru, jak píšete, tam není důvod používat Mustache.