Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proof of concept #350

Open
esteban-gs opened this issue Jun 13, 2023 · 1 comment
Open

Proof of concept #350

esteban-gs opened this issue Jun 13, 2023 · 1 comment

Comments

@esteban-gs
Copy link
Contributor

esteban-gs commented Jun 13, 2023

Proof of concept Messages & Notifications

We were trying to implement fully implement sockets in-house, but after taking into consideration the lift required to implement sockets, we might be better off with other approaches. This is probably not going to be viable to achieve for beta, so let's explore some simpler alternatives.

Current Proof of Concept
Shows what it would take to implement sockets in-house.
#314

Possible Approach:
Simple HTTP Polling/long polling.

Acceptance Criteria

  • We have a rough idea for how we can allow the front end app to post messages to the backend
  • We'll need to have a mechanism that http polls the back-end for new messages in rooms at an interval. There are some great examples of React interval hooks: https://github.com/streamich/react-use/blob/master/docs/useInterval.md
  • We have demonstrated how we can check for new unread messages or unread notifications from the backend at an interval
@esteban-gs esteban-gs added this to the Messaging b4 beta milestone Jun 13, 2023
@esteban-gs esteban-gs changed the title Research: Real-time chat provider Proof of concept Nov 7, 2023
@skyfox93
Copy link
Contributor

I can add some comments to clear this up, but since I've already got the websockets working, I think Its easier to just go with websockets for now, and then add this refactor to the backlog.

There is one blocker/ confusion - is an organization tied to a single user account or can multiple users belong to an organization? This makes a difference in how we know a message is read - easiest thing is to just add a boolean read indication whether it was read. However, if a message has multiple recipients, the logic is a little different and we need to track which recipients have read it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants