Home » Nodejs » Angular2 + Laravel with Real time & WebSockets

Angular2 + Laravel with Real time & WebSockets

Posted by: admin November 30, 2017 Leave a comment


I built an app and i’m planning to make a real time battle with Angular 2 and laravel. For example, you hit the “attack” button, and your opponent see his life going down in real time.

My app built with:

frontend: Angular 2

Backend: PHP Laravel 5.2

Now I’m searching and learning for my real time battle component,
and I saw different guides and tutorials for it:

  1. https://www.codetutorial.io/laravel-5-and-socket-io-tutorial/
  2. http://4dev.tech/2016/02/creating-a-live-auction-app-with-angular-2-node-js-and-socket-io/

The first tutorial is about how to use Laravel 5 and socket io.

The second one is how to use Angular 2 with NODS JS and socket io.

When I say real time, I mean that both users see the same thing that is happening on the screen)

My Backend and Frontend are totally divided and I have no setup with NodeJS anywhere in my app.

Both users need to see actions happening during a battle in my app, and It need to go through my laravel API and shown via my Angular 2 battle component

My question is –

What’s the best approach to real time app (seem websockets) using Angular2 and Laravel 5.2 to get the desired result of what I’m trying to achieve?



Laravel in this context is just templating and serving the client files, and acting as an interface inbetween the client and the socket.io server. It doesn’t actually act as the socket.io server, and I don’t believe it can.

So yes, you would still need something (node) to host the socket.io server to interact with the client, through PHP or otherwise. Personally, I’d skip Laravel/PHP altogether and just use node with koa/express/whatever to template your client (html/js/css/etc) files. Feels like an unnecessary abstraction to me.

The code below from socket.blade.php already has a connection to the actual socket.io server, so I don’t see why the additional overhead of an HTTP POST through PHP/Laravel is a good idea. Security, perhaps, but you can handle that with the actual socket.io server as well.

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


If you are planning to use websockets then there seems to be less use of laravel as only one socket is pretty capable of handling all the data that will be exchanged between the frontend and the backend, so if you don’t mind changing your engine you can try Meteor, https://www.meteor.com/


For the real-time character of your use-case, websockets are definitely the way to go. The players that should get the updates should be in the same ‘room’, so you can broadcast changes more easily. For the other functionality you can either use websockets or regular API calls to your backend directly from your client-side app code with some kind of communication between your api and the socket server, e.g. through Redis.


  1. All data through sockets, node server does api calls and broadcasts changes to active players
  2. Use API from app directly, use pub/sub queue foo for communication between laravel and node to broadcast changes to active players

Option 1:

  • Angular frontend app
    • Set up websocket connection
    • Add triggers for game foo which will send data over the socket connection and is handled by your nodeserver
    • Only talks to sockets
  • Node server
    • Serves frontend app
    • Handles socket connections, divide players per game
    • Handles socket calls and calls laravel api to do mutations on your data
    • Process action and broadcast changes to players in game X
  • Laravel REST API
    • Auth x
    • Default CRUD foo

Option 2:

  • Angular frontend app
    • Talks to api directly
    • Uses sockets to listen for updates
  • Node server
    • Serves frontend app
    • Handle websocket data
    • Listen on queue for published data from API
    • Broadcast changes to players in game x over socket
  • Laravel REST API
    • Auth
    • Crud
    • Mutation x triggers publish in Redis or other queue, which the node server can/should listen on

I’m sure there are more ways you can set this up, you just have to decide where you want what. Maybe introducing Redis is something you do not want, in that case your node app will have more to do. If you do want to use something like Redis, you’ll need to do API calls from either your frontend app or choose to do it through the node app anyway, combining the 2 options.