Ho preso in considerazione molte implementazioni, con diversi tipi di metodi di connessione, ed è così che vedo la scelta.
Dal punto di vista dello sviluppatore, FastCGI è fuori moda, nello stesso modo in cui considerano C. dal punto di vista dello sviluppatore, il compito può essere svolto in modi più semplici.
Dal punto di vista dell'implementazione, HTTP non è un sostituto perfetto, tuttavia esiste una sovrapposizione sufficiente in modo che possano essere utilizzati per risolvere gli stessi obiettivi. Ma in realtà questa domanda riguarda l'implementazione e l'architettura, e non una domanda focalizzata sullo sviluppatore, quindi ti risponderò dal lato dell'ingegneria dei sistemi.
Nonostante ciò che ho sfortunatamente letto nei blog degli sviluppatori, FastCGI può essere una scelta migliore se utilizzata nelle circostanze appropriate. Separa una grande preoccupazione complessa, che altrimenti deve essere implementata più in alto nello stack.
Ad esempio, ti permette di evitare di creare un robusto server web all'interno del tuo framework / linguaggio. Un compito enorme se davvero ti interessa la qualità, ma molto fattibile se lo schiaffi insieme come la maggior parte. Quindi è ironicamente più facile arrotolare tutto in una palla di spaghetti, quindi separare in modo pulito quella parte. Questo è il motivo per cui così tanti evitano FastCGI, perché potrebbero solo implementarlo quasi avvolgendo HTTP comunque, a causa delle loro cattive scelte architettoniche.
Dato che non hai avuto informazioni più dettagliate su quanto sia ambizioso il tuo piano, non posso davvero darti ottimi consigli. Consentitemi di suggerire alcune cose da indagare, che non sono lo slap comune dello stile del nodo python.
Leggi i dettagli di implementazione di,
php-fpm
Se vuoi fare un altro modello di appserver, fallo bene, leggi
uwsgi