Running Laravel Websockets in production — Setting up a dedicated websockets server.

Setting up websockets for a single application

This is a continuation of the ‘Running Laravel Websockets in production’ tutorial series. This tutorial is part of a 4 part series, as shown below.

1. Initial configuration — Start here, then choose one of the deployment architectures below.
2. Setting up a websockets for a single application.
3. Setting up websockets for multi-tenant application
4. Setting up a dedicated websockets server. — This article

If you haven’t looked at the previous tutorial which includes setting up the initial configurations i.e., the web sockets server itself and supervisor kindly read it here.

Introduction

This deployment model allows us to reuse the same websockets server. Sort of like a like microservice.

We set up a dedicated websockets server, either as part of our application or an entirely different standalone application. In short, it’s like just downloading the Laravel websockets package and running it as a standalone application.

In this approach, we will be connecting the client browser using echo JS specifically pusher to our websockets running on https://ws.example.com. the above instance, the Laravel application is multi-tenant. In the example, https://app1.example.com, https://app2.example.com and https://example.com are all standalone applications.

Pros

• Can serve more than one application with this approach.
• Easy to scale.

Cons

• Harder to set up

Step 1 — Customizing supervisor

This has already been mentioned in the first article. I’ll just put the config files for reference purpose.

[program:laravel-websockets]
directory=/path/to/project/root/directory
command=php artisan websockets:serve --host 127.0.0.1 --port 6000
numprocs=1
user=[user] ;e.g. admin
autostart=true
autorestart=true
stderr_logfile=/var/log/websockets.err.log
stdout_logfile=/var/log/websockets.out.log

After setting this configuration you can simply start supervisor by running service supervisor restart or if the service is not running then simply run service supervisor start

To check if your websockets is running, then use the command supervisorctl statusor service supervisor status

Please note we are running the websockets from localhost, this is by design in that we will proxy the requests from clients to the websockets running on localhost.

Step 2 — Setting up reverse proxy

This is the most important step, and you should read this carefully.

We will be setting up reverse proxies for apache2 and nginx.

As a general tip, we are simply proxying the request to our websockets server being served on http://127.0.0.1:6000 as defined on the supervisor config above.

Nginx

The following will be the configuration for nginx. Add the following configuration to your existing Laravel app nginx configuration.

...
location /app/ {
    proxy_pass http://127.0.0.1:6000/app/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
}
location /apps/ {
    proxy_pass http:127.0.0.1:6000/apps/;
    proxy_set_header Host $host;
}
...

For example, the configuration below is for our site https://ws.example.com

Apache2

For apache make sure that the apache mod_proxy is enabled, a tutorial on how to do this can be found here. Add the following configuration to your existing web application configuration.

...
ProxyPass "/app/" "ws://127.0.0.1:6000/app/"
ProxyPass "/apps/" "http://127.0.0.1:6000/apps/"
...

For our example website, the configuration will be.

General warnings and tips

As a general tip, your app should avoid using the app/ and the apps/ route to avoid conflicts with the websockets server.

Step 3 — Laravel config files.

This shows the configurations for the Laravel web project.

Depending on the approach one will take here, some few thongs will change. There are two main approaches we can use.

1. Prefix the channel name in your PHP files.
2. Set up another app in websockets.php file

The difference between approach 1 and approach 2 is that, in approach 2 we are setting up an entirely new pusher application with different credentials. On the other hand, approach 1 reuses the same pusher credentials.

websockets.conf (Approach 1)

There will be no change to the default websockets.conf file

broadcasting.conf (Approach 1)

echo.js (Approach 1)

A dedicated script file for echo js

File prefixing example

channels.php route file

Example usage blade.php

websockets.conf (Approach 2)

For approach 2 we will need to add a new application to the websockets.conf

Note that the credentials for the new app 2 and app 3 need to be supplied from .env file.

broadcasting.conf (Approach 2)

No major changes here

echo.js (Approach 2)

A dedicated script file for echo js. In this case since the application are different, we use the default js files.

Conclusion

You should have a running websocket application by now. If you are interested in another deployment model, choose from one below.

1. Setting up websockets for a single application. — You have one application and one tenant, i.e., the normal set-ups.
2. Setting up websockets for multi-tenant application