smart Socket.io integration

Socket.io

Socket.io is probably one of the most common tools for managing real-time data transfers. It consists of the client, which runs in the browser, and the server. Socket.io is commonly used for fast data exchange in online games, chats, data-intensive web applications, bandwidth that demand high exchange rates, push notifications, etc. Socket.io is relatively easy to use. However, there are several inconveniences and problems. In this article, we will describe some of those.

Network traffic

Socket.io does not use network traffic rationally enough since it sends a lot of requests, namely:

  • GET for receiving HTML page
  • Socket.IO client library (207kb)
  • Three long polling Ajax requests
  • UPGRADE for WebSockets connection

A fairly large volume of 207 kb is used per request with the Socket.IO client library - this is a lot

Possible problems

Let's look at an example of a project with ReactJS front-end and Laravel on the back end when on the front-end side, there are not many nuances, since here you only need to understand that when working with a large amount of dynamic data that you can interact with, change the state, and accordingly, each such data element will have to listen for events through sockets, and at any moment new data may come, on which it will be necessary to separately hang all the crucial socket events only on it alone since the subscription to events is not overwritten, but accumulated. Therefore, it is essential that for each data element, a maximum of socket events is subscribed one time But there are more nuances on the back-end. When configuring a server socket on hosting in one instance, there are no configuration problems. In the case of setting up two environments for the project on one server, for the dev version, you will also need to run your socket server on a separate unoccupied port. By default, for the pro version, the socket server is running on port *: 6000. The first thing to pay attention to, you need to take any free port (for example, 3000, 4000, 5000, 6000). Having previously checked if there are any listeners on it, sudo lsof -i -P -n | grep LISTEN If there are no listeners on the port, then it is free, and we can use it in the laravel-echo-server.json config. The second important point, in the laravel-echo-server.json config, you need to register a separate storage. For example, for a production server

"sqlite": {
     "databasePath": "/database/laravel-echo-server.sqlite"
}

For deva
"sqlite": {
     "databasePath": "/database/laravel-echo-server-dev.sqlite"
}
The total will look like this:
PROD:
"host": "127.0.0.1",
"port": "6001",
"sqlite": {
     "databasePath": "/database/laravel-echo-server.sqlite"
}
Virgo:
"host": "127.0.0.1",
"port": "3000", (for example)
"sqlite": {
     "databasePath": "/database/laravel-echo-server-dev.sqlite"
}


Proxy forwarding in nginx configs:
Dev:
location / ws / {
                proxy_pass http://127.0.0.1:3000/; (Works WITHOUT https)
                proxy_http_version 1.1;
                proxy_set_header Host $ host;
                proxy_set_header Upgrade $ http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header X-Forwarded-For $ remote_addr;
                proxy_cache_bypass $ http_upgrade;
        }
Prod:
location / ws / {
                proxy_pass https://127.0.0.1:6001/; (https works)
                proxy_http_version 1.1;
                proxy_set_header Upgrade $ http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header X-Forwarded-For $ remote_addr;
        }

After all the changes and settings, remember to restart the echo server and nginx. The supervisor starts the echo server, so you can rebuild it through the supervisor

supervisorctl restart echo-server-dev: * (dev)
supervisorctl restart echo-server: * (cont)
systemctl restart nginx

* Names of ports, domains, and repositories do not have to follow this example. The main point is that when configuring two echo server instances on the same machine, the ports, and storage (databaseConfig) must be different. You can debug the launch status of the echo server through the log file, the path specified in the supervisor config for each instance. Before starting the echo server, you need to make sure that the echo server binary itself is in the source code node_modules / laravel-echo-server / bin / server.js. For this, you need to execute

npm i

These are some simple pieces of advice to help avoid problems during Socket.io integration.