Running Laravel Websockets in production — 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.
- Initial configuration — Start here, then choose one of the deployment architectures below.
- Setting up a websockets for a single application. — This article
- Setting up websockets for multi-tenant application
- Setting up a dedicated websockets server.
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 is the most common and basically what we are interested in is having one web sockets server, serving just one application.
In this approach, we will be connecting the client browser using echo JS specifically pusher to our websockets running on https://example.com.
In the above instance, both the Laravel application and websockets application will be running on the same domain. Replace the example.com with your own domain/IP.
Pros
- Easier to debug.
- Simpler configurations required.
- Easier to set up.
Cons
- Serves only one application.
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.logAfter 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://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.
websockets.conf
There will be no change to the default websockets.conf file
broadcasting.conf
echo.js
A dedicated script file for echo js
Conclusion
You should have a running web socket application by now. If you are interested in another deployment model, choose from one below.
