@rob25111: ti stai pericolosamente avvitando, fino al punto di non capirci più niente.
Partiamo dal presupposto che ogni software che voglia comunicare su una rete telematica, lo fa tramite socket. Crea un socket e si mette in ascolto su una data porta. Tramite questo socket è in grado di ricevere le richieste di connessione da parte di altre entità.
Apache fa questo. Apre il suo socket e ascolta. Appena un client/browser gli chiede una connessione, crea un altro socket appositamente per il nuovo client e userà quello per scambiare i messaggi.
Chiaro che qualsiasi software in grado di usare i socket ( o astrazioni degli stessi ) può fare altrettanto. Node.js è un ambiente runtime basato su V8 e quindi è in grado di eseguire codice Javascript. Rispetto al V8 usato nei browser, ha una serie di estensioni che gli consentono di interagire col sistema operativo in maniera "completa". Questo gli permette di usare i socket. A questo punto credo sia chiaro che un programma Node.js è in grado di fare quello che fa Apache.
E PHP? Può fare le stesse cose
https://www.php.net/manual/en/book.sockets.php
E Python? Hai voglia.
Non esistono ambienti di programmazione che vivano confinati nel web server ( Apache, Nginx e compagnia ).
E allora come interagiscono con un web server? Un tempo si usava l'interfaccia CGI ( ed è ancora usata in certi casi ), che si basa sul redirezionamento degli standard stream. Uno standard stream è un canale virtuale di comunicazione usato da sempre nei sistemi operativi. Hai presente lo standard input del C? Standard output? Standard error? Questi sono gli stream standard. Nei sistemi Unix è visibile ed utilizzabile esplicitamente il meccanismo del redirezionamento di questi stream.
Hai mai visto questo simbolo | in un comando Linux? Questo è il simbolo di pipe e consente d'inviare l'output del comando a sinistra del simbolo nell'input del comando a destra. Il tutto avviando i due comandi/programmi specificati.
Cioè
Codice:
cat pippo.txt | grep stream
Sto dicendo che deve listare il contenuto di pippo.txt ed inviarlo al comando grep che cercherà la stringa stream al suo interno. Cat è un comando della shell e vabbè...ma grep è un programma e la shell deve prima avviarlo per poter eseguire la mia pipe.
Chiaro il punto? Apache è in grado, tramite CGI, di avviare lo script specificato ( in PHP, Python o che altro ), redirezionare gli stream di input e output e di fatto comunicare con lo script in maniera bidirezionale. E' evidente che così puoi fare quello che ti pare. Apache comunica con i client e può inviare/ricevere parte dei dati ricevuti/da inviare al client allo script specificato.
E lo script potrebbe benissimo essere un programma in C++!! Mica solo i linguaggi di scripting possono farlo.
Attualmente Apache e compagnia implementano moduli nativi che consentono d'interagire con gli script in maniera più efficiente. Ma il concetto di base è sempre quello.
Detto questo, l'esecuzione e il codice dello script restano confinati sul server. Lo script invia il suo output ad Apache e Apache lo gira al client. E quest'output dev'essere qualcosa che il client possa capire. I browser, per esempio, capiscono solo Html, Css e Javascript. Punto. Se gl'invii codice PHP semplicemente non sanno che farsene.
Ed è la ragione per cui DispatchCode scrive "PHP non interagisce col DOM". Non può. Il DOM è una rappresentazione del documento html che sta nel browser, ma il codice non può accedere a quello che sta nel browser. Lui è confinato all'interno del server. Solo uno script Javascript che venga inviato al browser ( uno script Node.js che gira sul server non è in esecuzione nel browser, ma sta sul server!!! ) può interagire col DOM.
Stesso discorso vale per Webassembly.
Per cui non confondere il fatto che un web server come Apache abbia dei meccanismi per avviare ed interagire con degli script e/o programmi sul server, con quello che degli script e/o programmi possano fare.
Un programma/script è un programma e può fare tutto, compreso usare meccanismi di comunicazione su reti telematiche e meccanismi di ipc che gli consentano di comunicare con altri programmi in esecuzione sullo stesso computer.
E chiunque sia in grado di usare i socket, può fungere da server di qualsiasi tipo, web server compresi. Tant'è che Node.js e Go sono usati spessissimo per creare i cosidetti web services, cioè dei serverini specificamente creati per rispondere a certi tipi di richieste da parte dei client. Chiaro che un web server completo in Node.js sarebbe folle, dato che ti basta installare Apache, Nginx, Lighttpd e similari. Perchè reinventare la ruota?
