Utiliser Node pour executer des fichiers PHP

[Sephi-Chan]

À quel besoin cherches-tu à répondre ?
Quels sont les avantages de la solution que tu proposes ?


Maintenant, prenons une solution classique : un serveur Nginx ou Apache qui accepte des requêtes entrantes sur le port 80 avant de les router à des workers PHP qui tournent sur d'autres port (avec PHP-FPM). L'avantage, c'est que ces workers sont disponible dès la réception de la requête : le système n'a pas besoin des les lancer, d'exécuter le script et de les quitter. C'est simple et efficace.

[ToraTora]

Je veux ajouter uen couche de temps réelle à une application déjà existante.
J'utilise du AJAX en ce moment pour les requêtes asynchrone que je voudrais remplacer par node.

Les avantages ? Je ne sais pas, c'est pour ça que je demande si utiliser node convient à ce genre de situation
je ne connaissais pas PHP-FPM, merci je vais regarder ça !

[demenvil]

Pour quelles raisons tu voudrais utiliser Node.js ?

[Sephi-Chan]

Je veux ajouter uen couche de temps réelle à une application déjà existante.
J'utilise du AJAX en ce moment pour les requêtes asynchrone que je voudrais remplacer par node.

Les avantages ? Je ne sais pas, c'est pour ça que je demande si utiliser node convient à ce genre de situation
je ne connaissais pas PHP-FPM, merci je vais regarder ça !

Pour mettre en place ta couche de temps réel, tu as besoin de deux canaux de communication (ou d'un seul qui est full duplex) : un pour permettre une communication du client vers le serveur, et l'autre du serveur vers le client.

Pour communiquer du client vers le serveur, c'est facile : Ajax. On le fait déjà depuis des années, ça fonctionne très bien et c'est efficace. Note qu'on peut aussi utiliser Websocket pour ce type de communication, mais à ce jour on utilise rarement Websocket seul mais plutôt des outils qui font abstraction du moyen technique. Bref, Ajax est le plus simple (d'autant qu'il est direct : du navigateur vers l'application PHP).

Pour la communication du serveur vers le client, on doit utiliser des mécanismes de push. Là encore, il y a Websocket, le long polling, les Flash sockets, etc. Une fois de plus, on préfère utiliser des abstractions (Juggernaut, Socket.IO, Faye, etc.) ou carrément des services Web (Pubnub, Pusher, etc.). Le fait est que ces abstractions sont souvent basées sur Node. Le principe est simple : le serveur de push maintient des connexions avec les navigateurs et quand l'application Web a besoin d'envoyer une information sur un canal, elle l'indique à ce serveur de push qui s'occupe d'envoyer les messages aux navigateurs inscrits à ce canal.

Ce découpage a l'avantage d'être très simple : ton code métier est écrit en PHP (ou Python, ou Ruby, etc.) et ton serveur de push se cantonne simplement au rôle de messager. Ça permet d'avoir un système qui reste performant puisque chaque composant (le serveur de push et l'application PHP) est isolé et s'en tient à son rôle, et peut donc être optimisé individuellement.

[Astarion]

Le jeu que nous sommes en train de concevoir étant aussi en temps réel, je me suis posé les mêmes questions et Sephi-Chan apporte son lot de (bonnes) réponses !
Ayant passé près de 15 jours à rechercher et à tester toutes les solutions possibles pour mettre en place un serveur Websocket, j'en suis arrivé à la même conclusion que Sephi : L'utilisation d'un serveur Node.js avec Socket.io est la solution la plus simple et la plus performante !

L'utilisation de Node.js qu'en serveur de push permet effectivement d'avoir un code très clair et très compartimenté, sans besoin de recoder tout le code "métier" qui s'adapte très bien à se fonctionnement...

Un très bon tuto pour Socket.io (il y a aussi une partie sur Node.js) : Atinux - Socket.io

Jsuis dispo s'il faut un peut d'aide la dessus !