Angular2 + Laravel avec temps réel et WebSockets

Dans ce contexte, Laravel se contente de modéliser et de servir les fichiers du client et d’agir comme une interface entre le client et le serveur socket.io. En réalité, il n’agit pas comme un serveur socket.io et je ne crois pas que ce soit le cas.

Donc oui, vous aurez toujours besoin de quelque chose (noeud) pour héberger le serveur socket.io afin d’interagir avec le client, via PHP ou autre. Personnellement, je sauterais complètement Laravel / PHP et utiliserais simplement le noeud koa / express / quel que soit le modèle de fichier client (html / js / css / etc). Se sent comme une abstraction inutile pour moi.

Le code ci-dessous de socket.blade.php déjà une connexion au serveur socket.io actuel, donc je ne vois pas pourquoi la surcharge supplémentaire d’un HTTP POST via PHP / Laravel est une bonne idée. La sécurité peut-être, mais vous pouvez également gérer cela avec le serveur socket.io actuel.

 var socket = io.connect('http://localhost:8890'); socket.on('message', function (data) { $( "#messages" ).append( "
"+data+"
" ); }); 

Si vous envisagez d’utiliser des websockets, il semble y avoir moins d’utilisation de laravel, car un seul est assez capable de gérer toutes les données qui seront échangées entre le serveur et le serveur. peut essayer Meteor, https://www.meteor.com/

Pour le caractère en temps réel de votre cas d’utilisation, les Websockets sont définitivement la voie à suivre. Les lecteurs devant recevoir les mises à jour doivent se trouver dans la même “salle” afin que vous puissiez diffuser les modifications plus facilement. Pour les autres fonctionnalités, vous pouvez utiliser des websockets ou des appels d’API réguliers vers votre backend directement à partir du code de votre application côté client avec une sorte de communication entre votre API et le serveur de socket, par exemple via Redis.

TLDR:

1. Toutes les données via des sockets, le serveur de noeud effectue des appels api et diffuse les modifications apscopes aux lecteurs actifs.
2. Utilisez directement les API de l’application, utilisez pub / sub queue foo pour la communication entre laravel et le nœud afin de diffuser les modifications apscopes aux lecteurs actifs.

Option 1:

• Application frontale angular
  • Configurer la connexion websocket
  • Ajoutez des déclencheurs pour le jeu foo qui enverront des données via la connexion socket et seront gérés par votre serveur de nœuds
  • Parle seulement aux sockets
• Serveur de nœud
  • Sert l’application frontend
  • Gère les connexions de socket, divise les joueurs par match
  • Gère les appels de socket et appelle laravel api pour effectuer des mutations sur vos données
  • Traiter l’action et diffuser les modifications aux joueurs du jeu X
• Laravel API REST
  • Auth x
  • CRUD foo par défaut

Option 2:

• Application frontale angular
  • Entretiens avec api directement
  • Utilise des sockets pour écouter les mises à jour
• Serveur de nœud
  • Sert l’application frontend
  • Gérer les données websocket
  • Écouter dans la queue les données publiées à partir de l’API
  • Diffuser les modifications apscopes aux joueurs dans le jeu x via le socket
• Laravel API REST
  • Auth
  • Crud
  • La mutation x déclenche la publication dans Redis ou dans une autre queue sur laquelle le serveur de noeud peut / doit écouter

Je suis sûr qu’il y a plus de façons de mettre cela en place, il vous suffit de décider où vous voulez quoi. Introduire Redis est peut-être quelque chose que vous ne voulez pas, dans ce cas, votre application de nœud aura plus à faire. Si vous souhaitez utiliser quelque chose comme Redis, vous devez passer des appels d’API à partir de votre application frontale ou choisir de le faire via l’application de nœud, en combinant les deux options.