WebSockets+Ajax or just WebSockets?

Question

PHP

I am writing an interactive application based on WebSocket technology. I have already written the part responsible for sending messages, but the question arose about writing user interaction with the site. Simply put, situations when a user does something, and data about it is sent to the server.
Most examples on the Internet form a WebSocket + Ajax bundle, where sockets only send information to users, and Ajax requests are used the other way around, to send requests to the server.
At the same time, the WebSocket technology itself provides for the possibility for the client itself to send messages to the server. Thus, a dilemma arose - you can do it using Ajax, and based on the results of processing the user's request, simply broadcast the results through sockets, or you can [and, it seems to me, rather], work exclusively through sockets.
Please help me choose the right architecture!

Answer 1

Most of the examples on the Internet form a WebSocket + Ajax bundle,

First reason. Most often, there is already a server that has some kind of rest api, and then the need for notifications or something like that comes in, so ws is screwed on the right.
Second. Websocket is a bit more complex than http. It is necessary to take into account how to fumble calls between server instances, because a websocket can live for a very long time, unlike http, which takes no more than a minute. And also take into account the blocking, if some method locks the thread in which the call is being processed, then there will be a big trouble. Therefore, calls during processing should be non-blocking (suspend, async, etc) or perform each action in a separate thread, but there are not enough threads here, and it’s expensive to multiply threads. In general, it depends on the runtime environment.
Third. Message format. The websocket does not provide for any one message format, everyone must choose it for themselves. It's either json-rpc or grpc or graphql or something like that, which explicitly says that your #X call ended with a Y result. As opposed to http, which has parameters and some kind of response to these parameters. One, always.
Fourth. related infrastructure problems. Often nginx is used, and in the prod you do not connect to your own http server, but to nginx, which keeps the connection. If one of the parties falls off, then the second does not know about it right away (and sometimes at all). This is solved by setting up nginx, it requires knowledge, as opposed to http, where the default settings are minimal. Hence the problem of pings and pongs, they are in the protocol, but they cannot be controlled from the browser. People are asking for an API so that they can somehow process either pong or send ping, but alas, oh, this is not there. Therefore, such implementations as socket.io appear where the guys stuffed their self-written pings.
As I said, ws is more complicated than http, but not so critical, I omitted some difficulties in view of the fact that they already depend on the implementation tools, or just forgot. Well, there are few answers to your question, because as you can see the topic is sooooo extensive.

Answer 2

As I understand it, it’s unlikely that someone will answer me already, it’s a pity, apparently the question is too specific ... In general, according to the results, my decision was not to fence, it’s not entirely clear why Ajax is separate for WS, but to transfer all the work to WS, where for each service of my resource, there will be a WS-worker. They, in turn, are built on OOP in such a way that they inherit the parent class that passes them the methods for opening the worker, receiving and sending messages + a little on the specifics of the service, understanding where to send this or that user message, etc.
I hope I can help someone. I have already helped myself