Ciao Hatfield
Purtroppo la risposta al tuo quesito non è facile, anche perchè se non si conoscono le caratteristiche di un software è difficile stabilire bene i requisiti
Detto questo, ti parlo con l'esperienza di migrazione da un sistema vetusto ad uno un po' più moderno.
Nel caso specifico, il programma era scritto in Cobol, migrato a Java e recentemente a .NET
Personalmente credo che lato client la scelta migliore sia un'applicazione nativa al posto del browser. Il motivo è presto detto: nelle tue specifiche dici che i client sono tutti PC windows (quindi niente tablet/smartphone) e, soprattutto, che il client deve poter eseguire dei comandi a richiesta. Quest'ultimo punto è cruciale: le pagine web girano nella sandbox del browser e quindi non possono accedere alle risorse dei PC (file, eseguibili, ...). Ci si sta muovendo per consentirlo, ma ancora siamo molto lontani da una soluzione definitiva.
Prima di parlare di linguaggi di programmazione/struttura, sarebbe bene capire esattamente il tipo di performance che ci si aspetta... perchè spesso si parla senza cognizione di causa. Il problema è sempre capire quanto tempo possa passare fra il cambiamento di un valore sulla base dati e l'evidenza sul client di questo cambiamento.
Ho visto spesso gente affermare "deve essere immediato" e poi implementare una soluzione di tipo "long polling" fra client e server, così il dato cambiava e sul client veniva aggiornato dopo mezzo secondo. Alla richiesta di delucidazioni hanno risposto "beh, mezzo secondo è pressochè istantaneo"... Ma per me che sono informatico, quando si parla di perfromance alte, si parla di centesimi se non addirittura millesimi di secondo!
Se le tue prestazioni possono tranquillamente stare nell'arco di un paio di secondi, allora andrei su un'architettura abbastanza standard in questo periodo storico:
- Backend: espone tutti i servizi con delle api web. Ci sono una marea di librerie per tanti linguaggi, molte anche già pronte per gestire la sicurezza (autenticare gli utenti e verificare chi possa/non possa eseguire le chiamate)
- Frontend: applicazione nativa che, con librerie standard, si passa i dati
Se invece hai bisogno di performance avanzate, non saprei cosa consigliarti poichè ho usato i Socket decine di anni fa per togliere tutta l'infrastruttura Web (incideva di circa 20 ms a chiamata!) ma al giorno d'oggi c'è caso ci siano soluzioni migliori e più performanti
Veniamo ai linguaggi... Diciamo che qui dipende anche le conoscenze che avete.
Dovessi scegliere io, farei tutto con .NET:
- backend: se deve girare anche su Linux, puoi benissimo usare .NET core
- frontend: essendo tutti PC windows, secondo me è più pratico rispetto a Java. In molti casi è anche più performante a livello di esecuzione
Se però preferite usare Java perchè qualcuno già lo conosce e/o è più facile trovare risorse, va benissimo anche quello!
Per assurdo puoi anche fare il mix: un linguaggio per il backend e uno per il frontend.
Personalmente cerco di evitarlo perchè si crea la necessità di conoscere più linguaggi... però poi ognuno fa quel che vuole!
RECORD
Metto una nota a parte sul quesito legato ai record.
In realtà cerchi di stabilire una relazione fra la base dati attuale, probabilmente fatta di file e record, con una base dati completamente diversa (DB relazionale o documentale, non so).
Tieni presente che viene quasi spontaneo paragonare i file alle tabelle e i record alle tuple (righe).
In realtà la similitudine finisce lì!
A quel punto cambia proprio il modo di gestire la base dati (lock compresi), per cui se migri ad un nuovo linguaggio hai due opzioni:
- Abbandoni i vantaggi della nuova struttura: siccome i nuovi linguaggi nascono per le nuove strutture, abbandoni i vantaggi che questi ti offrono e resti a ragionare di file e record. Devi però farti tutto a manina, poichè non c'è un supporto nativo come c'era nei vecchi linguaggi. Al massimo puoi usare delle DLL fornite da chi gestisce la vecchia base dati, però cambia poco: è un qualcosa che va fuori dallo standard e quindi te lo fai a manina
- Inizi a ragionare secondo le logiche della nuova piattaforma. Hai una curva di apprendimento più alta (oltre ai linguaggi devi imparare i database), però i benefici sul lungo periodo saranno maggiori: sfrutti le potenzialità dei DB e oltretutto usi le features dei linguaggi moderi per queste strutture dati. Pensa che ci sono tanti ORM che ti consentono di scrivere codice che lavora su strutture dati generiche e loro fanno poi le query reali sul DB... ovviamente mettono uno strato in più che devi evitare se hai davvero bisogno di performance da urlo