What do you need to learn to write a chat widget from scratch?

Question

PHP

Hello toaster connoisseurs.
I am a beginner coder and for two weeks now I have been burning with the idea of ​​writing my own widget chat for my sites.
I don’t know which side to approach, I can’t decide which technology to read in order to start at least some progress in terms of development.
So far, the idea has hung on TK and what to write on (I'm more inclined towards PHP + JavaScript (one of its variations, I don’t know which one.) + MySQL):
1. Regular text chat
2. Users access via social networks
3. There should be the ability to send pm via p2p system i.e. sending private messages occurs directly to the user, without saving on the server. I understand this can be done somehow via WebRTC
4. To unload the server, the idea stuck in my head to work out the issue of sending a message not client-server-clients, but something more complicated, for example, client-server-several_clients-other_users, something like a terrent only for messages.
5. The code embedded in the site must be the same. I or someone I know wants to install the code and it immediately works, while messages from other domains do not intersect.
6. How to store it in the database. keep all messages in one table or is it better to choose something else?
7. I can't formulate the rest of the bunch of thoughts.
Maybe stupid ideas, but for the experience this would fit me.
And thanks for reading what I wrote.

Answer 1

Let's go through the points:
1) WebSockets
2) Everything related to authorization is not specifically related to the chat task. Of course, you can mess around, and take out the authorization functionality in a separate daemon or thread and communicate through Pub / Sub (for example, ZeroMQ). In fact, the main thing is that during user verification we could process other connections
3) If you want p2p message delivery with WebRTC, then you will only need a server for authorization and authentication of clients, and so that clients can find interlocutors. In this regard, the server part is simplified and the load requirements are reduced, but the client part becomes more complicated.
4) Unfortunately, you cannot broadcast messages because TCP is used. You can of course organize something like a queue, but I see no reason to win in performance. It's more a matter of architecture and how you synchronize user lists.
5) Well... I don't see a problem here. If you want to have one server for all widgets, then just add CORS support and request tokens (in headers) to distinguish between domains.
6) What exactly do you need to store in the database? Messages on your server, as you said, are not stored ... Users - any option, the same MySQL (or rather PostgreSQL, for which it is possible to use asynchronous queries to the database, which would be more interesting). Current users and stuff can be stored in Reddis etc. The main thing is that the storage is fast.
In general, the idea is interesting, there are a lot of implementation options. You can easily write this in PHP, there is ReactPHP + Ratchet for organizing a network of users, and you already want to use WebRTC to deliver messages. You just need to put a couple of daemons in the supervisor on the server (one per core) and put nginx on top, which will be the balancer and proxy. Given that you can pretty much reduce the final load on the server due to WebRTC and some architectural tricks, there should be no performance problems. It would also be nice for ReactPHP to put libev / libeven, in a word, you can go through the documentation there and read what and how.
update:
I am behind the times, just the same UDP can be used in browsers (at least in the latest builds of chrome), in particular, datachannels can be used to transfer information between browsers (and not audio and video) . So here everything rests on how to deliver messages between clients. The rest already depends on how you decide to do everything.

Answer 2

If fashionable, then using nodeJS. The solution is smart, puffing is resting, besides, the chat without brakes, as they say, is live. Load resistant.

Answer 3

Look towards WebSockets