Il y a le bon et le mauvais serveur
Le serveur web est celui qui parle http. Son rôle est de servir les assets statiques (si cela n’est pas délégué à un cdn) et de passer les requêtes au serveur d’application.
Le serveur d’application est responsable de faire le rendu html, grâce à un language de programmation, d’aller chercher les informations nécessaires dans la base de donnée et de faire le rendu, souvent grâce à un moteur de template.
C’est ce que l’on appelle l’architecture 3 tiers, web, app, bdd.
Apres, il y a encore beaucoup de choses qui peuvent entrer dans l’archi. Cache, waf, tls termination, object store… on va pas rentrer dans le détail.
Historiquement, les langages de l’époque, ne parlait pas forcément http nativement, perl, php ou python par example. Ils parlent CGI-bin, fastCGI ou WSGI (mais je ne connais pas trop tout ca) et donc dans ce cas là, il te faut un serveur web pour faire la traduction.
Il y a plusieurs raisons pourquoi nous sommes plus confus aujourd’hui.
Premièrement, il y a quelques années, les gens installait mod-php sur leur apache et bim, ça fonctionne. Ou est le web ou l’app?
Aussi, des langages plus modernes, comme rugby, nodejs ou go, parlent http nativement. Du coup, pourquoi mettre un serveur web devant?
Enfin, les serveurs web, comme HAproxy ou nginx, peuvent aussi faire tourner du lua ou même du js (regarde comment est fait le SSO de yunohost par exemple, de mémoire il sappelle SSOwhat en lua dans nginx ). Donc la ligne est carement flou.
Néanmoins, l’architecture 3 tiers est toujours celle recommandée. Pour des raison de performances. Php ou nginx ne servent pas les fichiers statiques à la même vitesse.
Et enfin sécurité, il me plaît de savoir que sur Internet, seul mon serveur web est exposé, et que celui-ci est stateless, et aussi incapable d’exécuter du script.
Voila, je me prétends pas expert, jai sûrement dit 2/3 bêtises, mais cest ma connaissance sur le sujet aujourd’hui et tu as quelques pistes pour creuser