The TutsPlus.com site has a new tutorial posted for the Laravel users out there ]introducing you to the framework's broadcast functionality](https://code.tutsplus.com/tutorials/how-laravel-broadcasting-works--cms-30500). Broadcasting in Laravel provides a simple interface to sending notification (such as emails or even real-time push messages) via a standardized interface.

Today, we are going to explore the concept of broadcasting in the Laravel web framework. It allows you to send notifications to the client side when something happens on the server side. In this article, we are going to use the third-party Pusher library to send notifications to the client side.

If you have ever wanted to send notifications from the server to the client when something happens on a server in Laravel, you're looking for the broadcasting feature.

The article walks through the scenario first and covers the basic flow of websockets and how they'd be used for messaging. From there they start in on the code, looking at the broadcast configuration and walking you through the setup of a Pusher account and the installation of the SDK. They help you configure the Laravel application for Pusher and install the Laravel Echo library for handling the messaging on the frontend. The tutorial goes through the code to create a "messages" table and hook in a "broadcast on" event. This is followed by the frontend setup including the Javascript to create the Pusher instance.

The SitePoint PHP blog has posted a new tutorial from Christopher Pitt that tries to answer the question wondering if React and PHP are compatible for game development.

“I’d like to make a multiplayer, economy-based game. Something like Stardew Valley, but with none of the befriending aspects and a player-based economy.”

I started thinking about this the moment I decided to try and build a game using PHP and React. The trouble is, I knew nothing about the dynamics of multiplayer games, or how to think about and implement player-based economies. I wasn’t even sure I knew enough about React to justify using it.

I once watched a talk by dead_lugosi, where she described building a medieval game in PHP. Margaret inspired me, and that talk was one of the things that led to me writing <a href="https://www.amazon.com/dp/1484224922>a book about JS game development. I became determined to write about my experience. Perhaps others could learn from my mistakes in this case, too.

With the foundation laid, he starts in on the setup of the backend for the game: a PHP server running a server compatible with multiple websocket (React) requests. He chose Aerys for the HTTP and websocket functionality and includes the code to create the server and the packages he required. He shares some of the code to create the server and a "Hello world" endpoint the frontend will use. He then moves over to the frontend side of things, showing the packages he installed via NPM and the Laravel Mix configuration to use Webpack to bundle up the files required. He then walks through the integration of the front and back end code including the connection of the websockets.

For those that want to see the end result all together he has posted it to GitHub in a complete form for this part of the series.

The SitePoint PHP blog has posted a new tutorial showing you how you can add real-time notifications to a Laravel application with the help of the Pusher service.

The modern web user expects to be informed of everything that happens within the application. You don’t want to be that one website that doesn’t even have the notifications dropdown found not just in all social media websites, but everywhere else these days, too.

Luckily, with Laravel and Pusher, implementing this functionality is a breeze. The code we’ll write in this tutorial can be found here.

Pusher makes use of Websockets to relay messages back out to waiting clients, sending a push notification (hence the name of the service) rather than waiting for it to poll them for the latest updates. The tutorial starts off by creating a new Laravel installation based on a "blog" example. It then creates the "followers" migration and model and builds out the relationships between it and the user handling. From there they show how to create the routes for following/unfollowing users, the code to perform the action and how to use Laravel's own notifications functionality to integrate with the queue. With that in place they include code to show the current messages (last five) and output the Javascript required to push the messages out to waiting clients.

In a post to his site Gonzalo Ayuso shows you how to combine authentication between Socket.io and a PHP frontend running a simple Silex-based application.

Normally, when I work with websockets, my stack is a socket.io server and a Silex frontend. Protect a PHP frontend with one kind of authentication of another is pretty straightforward. But if we want to use websockets, we need to set up another server and if we protect our frontend we need to protect our websocket server too.

If our frontend is node too (express for example), sharing authentication is more easy but at this time we we want to use two different servers (a node server and a PHP server). I’ve written about it too but today we`ll see another solution.

He sets up a simple Silex application with three routes - the root (/), a login route and a "private" one requiring a user to be logged in. This last route makes the connection to the websocket server in the template. This connection sends the current session ID to the backend where it's verified with a simple Socket.io middleware. Sometimes the session ID cookie will be set as HttpOnly so he provides an alternative for that: a new endpoint just for getting the current session ID for the websocket request.

On the SitePoint PHP blog they've posted a tutorial showing you how to build a chat application with Ratchet, a library in PHP that lets you work with WebSockets for more real-time communication between your frontend and backend systems.

In this tutorial, we’ll be taking a look at Ratchet, a PHP library for working with WebSockets. Let’s start by defining what WebSockets are. MDN says: "WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply. Connected computers image."

WebSockets allow us to write applications that can pass data from the browser to the server and vice-versa in real-time.

They start by helping you get Ratchet installed (via Composer) and start immediate in on the code. They create the application namespace, a Chat class and client to handle the WebSocket connection. They create methods for the open, close, write and read for the connection and make a simple script with a Ratchet server to handle the messaging back and forth. They also explain the various pieces of the system: the IoServer, HttpServer and WsServer. Finally they help you create the HTML frontend (using jQuery and Handlebars) and the CSS/Javascript to finish off the functionality.

Gonzalo Ayuso has a quick post to his site showing you how to make a "PHP dumper" for websocket connections based on a simple Silex application.

Another crazy idea. I want to dump my backend output in the browser’s console. There’re several PHP dumpers. For example Raul Fraile’s LadyBug. There’re also libraries to do exactly what I want to do, such as Chrome Logger. But I wanted to use Websockets and dump values in real time, without waiting to the end of backend script. Why? The answer is simple: Because I wanted to it.

He shows how to create a simple socket server (with Express in Javascript) and the basic Silex application with a "DumperServiceProvider" added in that will handle returning the debugging data back to the waiting client. He connects the Silex application with the websocket and shows the code to listen for new messages on the socket and display them back out to the browser. You can see an example of the end result in this video on YouTube.

Gonzalo Ayuso has a new post to his site today showing how to create a TCP server daemon with PHP with help from the Ratchet toolset. Ratchet is a library that makes it easier to work with WebSockets directly from PHP.

In my daily work I normally play a lot with TCP servers, clients and things like that. I like to use Linux’s xinet.d daemon to handle the TCP ports. I’ve also written something about it. This approach works fine. The problem appears when we call intensively our xinet.d server. It creates one PHP instance per request. It isn’t a problem with one request in, for example, 3 seconds, but if we need to handle 10 requests per second our server load will grow. The solution: a dedicated server.

In a setup similar to how Silex registers callbacks, he's created a PHP-based server that listens on whatever ports are defined for incoming connections and processes the data accordingly. He includes several code samples that show it in use, both in simple request handling and more complex configurations based off of a YAML file definition. He ends the post with a method he uses to "emulate" threading in his processing with the help of a Silex app and HTTP requests to hand off the processed and remove the blocking problem PHP introduces.

While not a recent article, this post from Saran Chamling is definitely interesting. In it he shows you how to create a real-time chat by combining PHP and WebSockets.

The WebSocket is a feature of HTML5 for establishing a socket connections between a web browser and a server, once the connection has been established with the server, all WebSocket data (frames) are sent directly over a socket rather than usual HTTP response and requests, giving us much faster and persistent communication between a web browser and a server. Let’s create a simple chat system using this cool technology (HTML5 WebSocket and PHP).

He includes all the code you'll need to get things up and running, starting from the WebSocket side. With a simple socket connection and some jQuery to control it, the system connects to the backend PHP script. The PHP script reads directly from the socket (using the socket_* functions) and binds to it, waiting for incoming requests. There's also some sample code showing how to work with the "handshake" between the WebSocket and PHP and how to respond. If you want something a bit easier to work with and more functional, consider checking out Ratchet, a WebSocket server for PHP.

Michael Feichtinger has posted a simple websocket example to his blog today. It shows the creation of a simple "web chat" application for real-time communication without the mess that can come with ajax.

The classic example for websockets is a chat. This chat example has only 200 lines of code (excl. the Websocket class), is really easy to understand and customizable.

He creates a basic "WebsocketClass" class that (in his example) connects to an IP and port. It uses JSON as the messaging format and some basic javascript to handle the clicks of the "chat" and "login" buttons. You can see an example in action here and download the source for the server.php here.

Justin Ireland has posted an article to his blog about creating real-time interfaces for your sites using the combination of HTML, CSS and Javascript to connect to a physical interface on the backend.

Physical interfaces such as button panels or remote controls have many disadvantages. Panel controls require a dedicated display for feedback and physical access to a fixed location. IR remote controls offer only one-way communication with limited feedback and can become difficult to manage for multiple devices. [...] We propose a new type of solution to address these issues and bring simplified management and control to a broader market through embedded virtual interfaces.

He lays out the structure of the application, some of the issues that could come up in the connection (using COMET and Websockets). His proof of concept is a connection to a HDMI switch that can be talked to through an embedded controller via a simple interface.