willybeans / freedu_go Goto Github PK

this is connected to the frontend issue here
As a user, i will have my API interactions with web sockets go through a publish/subscribe structure

As a user, when i subscribe to a 'topic', i will be added to subscribers map, and my subscriber id will become associated with the appropriate topic ids as i subscribe to them. I should be able to interact with the topics that i want to subscribe or unsubscribe to, as well as remove myself from subscribers.

• our code should be able to create subscribers
• and be able to create topics
• as a subscriber, one should be able to subscribe to topics
• and unsubscribe to topics
• all subscribers should be able to list all topics they have subscribed to
• all topics should be able to list all of the subscribers subscribed to them
• we should be able to delete subscribers
• we should be able to delete topics

open questions:
is there a need for destroying subscriber objects on disconnect, or only on deletion (ie, user deletes account?) Mani believes we should keep everything in memory.

As a user, all of my interactions with the pub/sub architecture should be persisted in memory

this is a virtual redis server, that stores a json cache of all previous database interactions to speed up database queries.

just focus on user stories 1,2, and 3

### User Story 1: As a User, I want to be able to join a "chat", so that I can communicate with other users in real-time.

Acceptance Criteria:

I should be able to see a list of available "chats".
Upon selecting a chat room, I should be successfully joined to that room. (ie, see the previous chats)
The chat room interface should provide real-time updates of messages from other users. (this will be implemented later with websockets)

User Story 2: As a User, I want to send messages in a chat room, so that I can communicate with other users.

Acceptance Criteria:

There should be a text input field in the chat room for typing messages.
Messages sent by me should be displayed in real-time for all users in the chat room. (later with websockets)
Messages should display the sender's username, timestamp, and the content of the message.

User Story 3: As a User, I want the ability to edit or delete my own messages, so that I can correct mistakes or remove inappropriate content.

Acceptance Criteria:

There should be options available to edit or delete messages that I have sent.
Editing a message should update the message content in real-time for all users in the chat room.(later with ws)
Deleting a message should remove it from the chat room for all users in real-time.

SKIP THIS

User Story 4: As a User, I want to see who is currently online in the chat room, so that I can know who I can communicate with.

Acceptance Criteria:

The chat room interface should display a list of users currently online.
The online user list should update in real-time as users join or leave the chat room.

SKIP THIS

User Story 5: As a User, I want to receive notifications for new messages when the chat room is not in focus, so that I don't miss any important conversations.

Acceptance Criteria:

When a new message is sent in the chat room, I should receive a notification.
The notification should include the sender's username and a preview of the message.
Clicking on the notification should bring me directly to the chat room.

TECHNICAL SPECS:

You may need to update the DB schema in order to accomadate any unforeseen additions to the functionality. The database is being generated by the .create_database.sh file, and you can update that as you make progress. it would be nice to have dummy data written in their upfront, but i can also do that later and isnt required.

most of your work will take place in the following files: ./routes.go ./handlers/...

you will need to make a new go file in /handlers/ to hold the logic for what you are writing

i would suggest running this on the front end through a simulator, since i haven't configured it to allow cors, or if you want, you could try to add that to the router.

As a User, i want to be able to have real connect interactions with the database through websockets.

• Using gorilla/websockets, establish a websocket connection
• generate initial messaging structure for speaking with the application
• confirm the following are accounted for: onmessage, onclose, ping/pong(heart beat)

consider moving the database interactions out of the handlers, and into their own file so they can be both referenced from websockets and from HTTP interactions

this is connected to this issue