"abilitazione web" di un'app C ++ esistente

Question

"abilitazione web" di un'app C ++ esistente

#1 da (2 voti)
#2 da (2 voti)

3

Ho un'applicazione Windows codificata in C ++. Voglio fornire loro un'interfaccia web, al fine di portarli su sistemi Linux embedded. Le pagine web sono una serie di "pagine di stato" dinamiche nel sistema, con possibilmente alcuni semplici controlli di interazione

Le moderne tecnologie HTML / CSS / Web sono relativamente nuove per me e sto cercando di elaborare un approccio sano per strutturare questo aspetto.

Il primo approccio consisteva nell'utilizzare un semplice server web integrato direttamente nell'applicazione Windows, con alcuni codici C ++ che scrivevano HTML in modo dinamico e che servivano alcune immagini css / javascript / statiche. Le insidie erano piuttosto ovvie: nessun HTTPS, contenuto e presentazione confusi: (

Ora ho pagine 'statiche' che usano JQuery per recuperare i dati JSON dalla mia app. Il server ora è nginx e utilizza FastCGI per estrarre i dati dalla mia app.

Quindi il processo è un po 'come questo:

Pagina richieste browser
Nginx serve la pagina con Javascript
Il browser esegue javascript e utilizza JQuery / getJSON per recuperare i dati di stato
Nginx inoltra JSON GET tramite fastcgi alla mia app
La mia app genera JSON e invia a nginx
Nginx inoltra JSON al browser
Il browser javascript utilizza i dati JSON per il rendering della pagina

Questo sembra un po 'macchinoso. C'è qualcosa di più intelligente che dovrei fare, magari usare server-side include con fastcgi per includere i dati JSON nella richiesta originale? Sto facendo qualcosa di orribilmente non convenzionale?

web-development jquery cgi

posta Roddy 18.03.2016 - 14:42

fonte

2 risposte

Leggi altre domande sui tag web-development jquery cgi

Esiste un caso per l'implementazione di una richiamata se viene restituito un futuro? Registrazione di un audit trail (applicazione Java)

score 2 · Answer 1

Ci sei quasi, ma a meno che la tua pagina non si aggiorni periodicamente da sola, il livello JavaScript / AJAX è davvero superfluo.

Se strutturi correttamente il back-end, puoi farlo generare sia il contenuto che della presentazione e inviare entrambi in formato HTML al browser, senza creare problemi. Ecco a cosa servono i modelli di presentazione!

Probabilmente prendi in considerazione l'idea di organizzare il tuo codice di back-end in una qualche forma del pattern MVC.

score 2 · Answer 2

Potresti utilizzare le FastCGI tecniche e librerie.

Potresti anche rendere l'applicazione C ++ un server Web specializzato utilizzando una libreria di server HTTP come libonion o Wt (entrambi sono compatibili con HTTPS e possono facilmente servire contenuto statico, da file o da dati di byte incorporati, come Javascript, CSS, caratteri, immagini, static testo ... ed entrambi hanno un qualche tipo di template che mescola HTML fisso con parti HTML dinamiche).

Quindi (con FastCGI o una libreria di server HTTP) eviterai l'onere (il vecchio approccio CGI ha ) di iniziare un nuovo processo per ogni richiesta HTTP .

BTW, alcune persone pensano che FastCGI sia obsoleto: affermano che dovremmo sempre codificare server HTTP specializzati in C ++ e forse usare e configurare ngnix (o qualche altro server HTTP comune come apache o lighttpd) per reindirizzare alcuni richieste HTTP al server web specializzato (quindi utilizzare il protocollo HTTP al posto di FastCGI per la comunicazione tra il tuo programma C ++ e ngnix).

Con una libreria server HTTP, non avrai bisogno di un server HTTP extra come ngnix (ma la tua applicazione dovrebbe fare attenzione a evitare arresti anomali). Con FastCGI, il tuo ngnix (o altro) server Web può essere configurato per avviare o riavviare l'applicazione C ++ FastCGI quando necessario. E FastCGI è in qualche modo progettato per interagire rapidamente con il server Web.

A meno che l'appliance non abbia lotti di client HTTP simultanei (cioè molte persone lo guardino allo stesso tempo), oa meno che non ti fidi della tua applicazione C ++, consiglierei una libreria server HTTP approccio (proprio per evitare il costo degli scambi FastCGI -che non costano molto nella pratica- e soprattutto per evitare la necessità di un server HTTP completo in abbondanza come ngnix ...)