两个用户客户端之间通过 REST API 与 PHP 后端、Z45EDC1B1和Node3507D9D2A03DD 进行实时通信

Question

Asking for architectural advice on how to design the system with public API for user clients communication.

I'm working on the project where two clients must be able to communicate at real-time (or close to that) with each other in the most simple way as possible. Let's introduce the resource which has to be accessed by two separate clients. The workflow is the following:

1. Client #1 connects to the server and creates the resource
2. Client #2 connects to the server and accesses the resource
3. Client #1 changes the resource
4. Client #2 changes the resource
5. Repeat steps 3 and 4 until done.

The client cannot act until opposing client has not acted - request order must be preserved.

---

Clients should be able to access the resource via REST API ( GET , POST , PUT , DELETE ). Each client must wait until the opposing client performs an action. Time for the client to respond and perform an action is about 1-2 seconds (can slightly differ).

Please note that system should be able to handle a high load of concurrent requests (multiple clients communicating at the same time).

The global goal of the application is to provide an API where clients programmed in multiple different languages could communicate at real-time without any polling implementation on the user-client side. User clients must be as simple as possible.

Pseudo user-client example

response = init();
while (response->pending) {
    response = get();
}

while (response->action_required) {
    response = act();

    if (response->error || response->timeout) {
        response = get();
    }
}

function init() {
    // POST resource.example.com
}

function act() {
    // PUT resource.example.com
}

function get() {
    // GET resource.example.com
}

---

The problem statement

Since each client must wait until opposing client to act there is a need to introduce the sleep() function in the code which will delay the response until the resource will be affected/changed by the opposing client.

The request polling must be omitted from the user-client and implemented in server side.

---

Current thoughts and proposal

The initial thought was to implement only the PHP backend and perform response delay inside the API function, however, this implementation seems to cause severe performance issues, so I'm thinking about a more sophisticated solution. Or maybe I am wrong and response delay can successfully be implemented with sleep() inside the PHP backend?

Proposed system architecture

• Node WebSocket server (socket.io to receive/return events)
• PHP backend with REST API (access/change the resource , fire events to WebSocket)
• Node JS application with public API for the end-user client (response delay functionality until the event received)

Please note that PHP backend cannot be replaced in this architecture, however, WebSocket and Node JS application are flexible units for the implementation.

Would be this kind of architecture implementable without severe server performance issues? Is there a better, more feasible way to design this kind of system? Is Node JS application able to handle multiple concurrent requests with response delay or any other kind of web application (Python/Ruby/...) would serve better? Is socket a must-have for this system in order to achieve somewhat real-time behaviour?

Please, share any ideas/insights/suggestions/... what could help to design this system in a sophisticated and well-performing manner.

Thank you in advance!

Answer 1

Some notes:

1. Avoid Sleep at all costs.
2. Your use case tends to lend itself to a pub/sub micro-services pattern.
3. As you need to preserve message processing order you need to have a common queue. Each of your REST API nodes act as a pub/sub publisher onto a distributed message queue system (RabbitMQ, Kafka, etc. type of tech). So for high throughput you now have a farm of machines handing the enqueue. They return immediately with a 201 Accepted, but need a way to mark the message with some kind of client identifier so you can route update messages back over web socket (if you aren't going to poll for status updates by resource id).
4. You need subscribers to this queue to do the actual processing. Same thing, have these as separate applications and now you can scale out the dequeue and processing. However, the tech you choose for the pub/sub bus needs to be able to invalidate subsequent messages for that resource, and for each one of the invalidated messages provide feedback to your application so that it can send the required message over web socket.

Hope this helps.