Share laravel-echo-server broadcast service construction

                                                                                                                                                                  

The following tutorial column will introduce you to the construction of laravel-echo-server broadcast service. I hope it will be helpful to friends in need!

Motivation

Many scenarios in current projects use Redis queues and scheduled tasks to handle tasks that take longer to execute. These tasks The execution status and execution results can only be obtained by re-sending a request from the front end.

Goal

In order to optimize the program experience and allow users to pay attention to the task execution results as early as possible, we have evaluated various options. In order to reduce the communication cost between the front and back ends and avoid reinventing the wheel, we decided to use the broadcast function built into the Laravel framework.

Select a service

Officially recommends using pusher to build applications. The advantage of pusher is that it is very simple to build. However, considering that it is a foreign service, there is a risk of access stability; and the current project scale is small, so I tried to build a Websocket service myself, using the tlaverdure/laravel-echo-server project officially mentioned by the Laravel framework.

laravel-echo-server service features

The usage method of this project can be obtained directly from their github page. The following points are what we like:

Event information can be obtained and broadcast through the publish and subscribe function of Redis. This is more efficient than sending push requests to pusher's HTTP API;

It is also compatible with pusher's HTTP API. If some services cannot publish events through Redis, you can use this mode to push events;

2. Building Websocket services

We initially used oanhnn/laravel -echo-server This image is used to start the container. During the debugging process, we found that this service is not stable. Node's service will exit directly when an exception occurs. This is the first pitfall we encountered. In order to quickly solve this problem, we added a supervisor based on this image to be responsible for the task of restarting the service process after exiting, and made our own image.

Redis Subscription

When trying out Redis subscription, in addition to the regular database address and password and other parameters, the key prefix is ​​another pitfall we encountered, corresponding to The keyPrefix configuration item in the laravel-echo-server.json file in the laravel-echo-server service did not find the correct method at the beginning, and it was incorrect no matter how it was configured. Later I found out that if you want to know the current Redis key prefix of the program that wants to broadcast the event, just execute the following script in tinker.

# php artisan tinkerconfig('database.redis.options.prefix');

Nginx proxy

Since the production environment uses the HTTPS protocol, I need to add a certificate to the service, but because I am a Node novice, no Node program uses the certificate Configuration experience, so I basically gave up after one round of attempts, and then adopted the Nginx proxy method to use the certificate. After several rounds of attempts, the configuration was finally successful.

server {
    listen port;
    server_name your-domain;
    ssl on;
    ssl_certificate     path-to-pem;
    ssl_certificate_key path-to-key;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    location /socket.io {
        proxy_pass http://container-name:6002;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }}

Private/Attendance Channel Authorization

Laravel broadcast divides channels into: public, private and attendance (I may have translated it wrong, please correct me), the latter two Authorized access is required. What we need to use is a private channel, so only authorized people can subscribe to our events from the front end. This is also a pitfall we encountered. After our observation and source code reading, we found that the overall authorization process of laravel-echo is:

The front-end program first sends an HTTP POST request to the laravel-echo-server service;

laravel-echo-server sends an HTTP POST to the application server based on the two items

authEndpoint
1. and
authHost
2. in the configuration. The POST data is the channel name and is transparently transmitted in the header. Authorization data; laravel-echo-server will determine the authorization result based on the response of the application server. If the application server responds with a non-HTTP 200 status, it means that an error occurred and the authorization failed.
We encounter two problems in practice. The first problem is that the authorization gatekeeping logic of our project is not laravel's default, so the routes introduced by the default
3. Broadcast::routes()
cannot be used directly. After discovering the problem, we re-added our own authorization route and configured it in the

authEndpoint

configuration item of laravel-echo-server.json. <p>Another problem is that we do not use the standard RESTFul protocol rules: respond to the corresponding HTTP Code to describe the error status. As a result, laravel-echo-server cannot detect the problem and feed it back to the front-end program even when authorization fails. The situation is similar to the picture below: </p> <p><img src="https://img.php.cn/upload/article/000/000/020/ce24538de7ea16b3b939356a59350b87-0.jpg" alt=""></p> <blockquote>##Sooner or later, you still have to pay off the debt. …<p></p> </blockquote> <h2>##Summary<span class="header-link octicon octicon-link"></span>The development of this function was not as smooth as originally thought. The main problems are as follows:</h2> <p></p>laravel-echo-server is not as robust as expected. I have to look for alternatives when I have time in the future. It seems that there are also projects using swoole. You can try it; <ol> <li>Forgot to consider the SSL problem in advance, resulting in The temporary processing during release was hectic; </li> <li>laravel-echo-server and laravel-echo themselves are small projects. When encountering problems, you should give priority to analyzing their codes to reduce the time of trying. </li> <li> </ol>

The above is the detailed content of Share laravel-echo-server broadcast service construction. For more information, please follow other related articles on the PHP Chinese website!