London | 26-JULY-SDC|Ping Wang | Sprint 2 | Chat-app CYF-1162

[pathywang]

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

Task code

CYF-1162

Changelist

I did prep then come for this task, deploy it and check with requirement.

Coolify deploy URL:

chat-app backend URL: https://mcc7a7ee5emoct93laditnv2.trainees.hosting.cyf.academy

chat-app frontend URL: https://5cswkpsyenndpkjbekkanjyy.trainees.hosting.cyf.academy

[LonMcGregor]

The core app works well.

The readme suggests you could add at least one additional feature - what feature did you choose? I can only see the basic messaging features.

Can you explain in your own words how your approach to long polling works? Are there any advantages / disadvantages to your approach?

[pathywang]

 Additional feature

Thank you for the comment. I think i added timestamps to message as additional feature so the users can see what time the message was sent each time. Each message is given a timestamp when it is created, and the frontend displays the time next to the username and message. Do you agree with it?

How my long polling works

When the frontend starts, it calls the backend using GET /messages?longPoll=true. The backend checks whether there are any messages that the client has not received yet. If there are new messages, it sends them immediately.

If there are no new messages, the backend does not immediately send a response. Instead, it keeps the request open and stores the response in waitingClients. This is the long-polling part.

When another user sends a message using POST /messages, the backend stores the new message and checks the clients that are currently waiting. It sends the new message to those clients and then their frontend starts another long-polling request.

The frontend therefore continuously waits for new messages without repeatedly refreshing the page.

Advantage

Long polling gives users near real-time updates without requiring the browser to constantly send requests at short intervals. It is also relatively simple to implement using normal HTTP requests.

Disadvantage

The server has to keep HTTP requests open while clients are waiting. With many users, this could use more server resources. Long polling also has more overhead than a persistent WebSocket connection because a new HTTP request needs to be made after each response.

Overall, I chose long polling because it is a relatively simple way to provide live message updates while using standard HTTP.

[LonMcGregor]

Good work. thank you for answering those questions. I didn't realise the timestamps were not one of the requirements, so that counts as a new feature. This task is complete now

[pathywang]

Many thanks for review my PR!