Server Web incorporato contro server Web esterno

Il principale svantaggio di gestire le tue richieste HTTP invece di utilizzare un server web esistente per il server della tua applicazione sono le innumerevoli ore di sviluppo necessarie per creare server Web in grado di gestire le richieste HTTP in modo più rapido e sicuro di qualsiasi altra cosa tu sia probabilmente per codice da solo. Se sei preoccupato per il sovraccarico, puoi sempre provare un server http leggero come Lighttpd o nginx e server applicazioni, LISP o qualsiasi altra cosa, usando FastCGI, o un modulo specifico per la tua lingua (wsgi per Python, ecc.).

Oppure puoi sempre utilizzare un Lighttpd o NGinx per il tuo contenuto statico e le richieste proxy di contenuto dinamico per l'applicazione o un server applicazioni appropriato per la tua applicazione.

Prima di poter rispondere correttamente a questa domanda, devi considerare quali sono le richieste per il gestore web e quali sono i tipi di interazioni che stai facendo? L'insieme di pro / contro può essere diverso a seconda di cosa stai facendo:

• Applicazione Web completa : utilizza un server Web esterno. Il server Web esterno verrà ottimizzato per gestire le richieste non dell'applicazione di contenuto statico (ad esempio immagini, fogli di stile, JavaScript e pagine HTML statiche). L'utilizzo di un buon framework web renderà la creazione dell'applicazione Web molto più semplice.
• Solo un paio di servizi Web : è un pareggio qui. Senza risorse statiche da utilizzare, è una questione di quanto è necessario ridimensionare. Più richieste anticipate anticipate, più vi spingono verso il server Web esterno. Il motivo principale è che i server Web esterni sono progettati per funzionare con bilanciamento del carico e altri approcci per condividere il carico di lavoro.
• Protocollo applicativo punto a punto : il server incorporato funziona al meglio. Sia lo sforzo di programmazione per gestire le poche (relativamente semplici) richieste, sia il traffico molto più basso che ci si aspetta rendono i server embedded attraenti. Puoi ignorare una grande quantità delle specifiche HTTP perché non sei preoccupato per il caching del browser e ti stai concentrando solo su ciò che ti serve alla tua applicazione.

Alla fine della giornata, un server incorporato può essere molto impegnativo. Potresti essere in grado di incorporare un server Web open source creato da qualcun altro per risparmiare tempo. In effetti, questo è l'approccio che i progetti di applicazioni web basati su Ruby on Rails e Maven utilizzano per eseguire test interni. Incorporano un server web nell'infrastruttura di compilazione per semplificare notevolmente il lavoro sul progetto. L'obiettivo finale per entrambi i tipi di progetti, tuttavia, è che il prodotto verrà distribuito su un server Web esterno.

L'unica ragione per cui incorporo un server web nella mia app è se avessi una ragionevole aspettativa che sarebbe stato installato in un ambiente in cui non potevo aspettarmi o richiedere un server web standalone. Tieni presente che la tua app potrebbe dover coesistere con altri server web, quindi dovrà essere configurabile (in particolare la porta). Quella configurazione è qualcosa che vuoi richiedere ai tuoi utenti?

Se questa è un'app sperimentale con una base utenti limitata e vuoi giocare, allora vai avanti! Ma nel "mondo reale" non vorremmo quasi mai farlo, come altri hanno menzionato. Ho implementato il mio server web in precedenza e, una volta che devi fare qualcosa di più che pubblicare pagine statiche e una semplice app, si trasforma rapidamente in un lotto di codice (anche se ignori la sicurezza e la scalabilità ).