Con Apache e NGINX gli utenti hanno a disposizione due progetti open source stabili e sicuri. Nessuno dei due web server ne emerge però vincitore assoluto. Alla base di entrambi i progetti si trovano delle scelte di design essenzialmente diverse che, a seconda di come viene utilizzato il software, implicano vantaggi e svantaggi.
Il server ApacheHTTP offre un immenso repertorio di moduli che apre al software grazie a opzioni di configurazione flessibili innumerevoli campi di applicazione. Il web server rappresenta il software standard per scenari di hosting condiviso e in questo ambito si affermerà anche sui web server leggeri come NGINX. La possibilità di integrare degli interpreti direttamente nel web server, tramite moduli per i linguaggi di programmazione come PHP, Perl, Python o Ruby, permette la consegna dei contenuti web dinamici senza dover ricorrere a un application server separato. Ciò rende il server Apache una soluzione pratica per siti piccoli e medio-grandi in cui i contenuti vengono generati dinamicamente durante il suo utilizzo.
Al contrario NGINX non offre nessuna possibilità di elaborare i contenuti dinamici di per sé o di integrare degli interpreti corrispondenti tramite moduli. Così è sempre necessario un application server separato, cosa che potrà sembrare uno sforzo inutile nel caso di siti piccoli e medio-grandi. Una struttura simile mostra però i suoi punti di forza in presenza di grandi progetti web e di un aumento del traffico.
Solitamente NGINX viene utilizzato come load balancer per un gruppo di application server. Così il load balancer accoglie le richieste e decide a seconda del loro tipo se queste devono essere inoltrate a un server specializzato che opera in background. I contenuti web statici vengono consegnati direttamente da NGINX. Invece, se un client richiede dei contenuti dinamici, il load balancer inoltra la richiesta a uno degli application server previsti per questo scopo. Questo server interpreta il linguaggio di programmazione, riunisce i contenuti richiesti in una pagina web e li restituisce a un load balancer che si fa carico di nuovo della consegna al client. In questo modo si possono gestire efficacemente flussi di traffico elevati.
In più NGINX memorizza già i contenuti scaricati nella cache per un determinato periodo, di modo che i contenuti dinamici richiesti possano venire consegnati di nuovo direttamente dal load balancer senza che NGINX debba ricorrere nuovamente all’application server.
La delocalizzazione dell’interprete su uno o più server back end separati ha il vantaggio che si riesce a scalare comodamente la serie di server, utilizzando server back end aggiuntivi, se necessario, o potendo disattivare i sistemi che non servono. In pratica molti utenti utilizzano una struttura di questo tipo, combinando NGINX e Apache e approfittando così dei punti di forza di entrambi i web server.