Milestone-D7

Nice-to-Haves:

N1: Communication
N3: Code execution
N4: Syntax Highlighting
N6: Generative AI
N7: Cloud Deployment

Functional Requirements

N1: Communication

Functional Requirement	Acceptance Criteria	Priority
N1. Communication
WebSocket Session	Backend creates and manages WebSocket sessions for users when they connect, maintaining session data (e.g., users, messages).	H
Message Handling	Backend processes "chatSendMessage" events, stores the message, and broadcasts it to all connected clients.	H
Session Join/Leave	Backend listens for "sessionJoin" and "sessionLeft" events and broadcasts to all clients when a user joins or leaves the session.	H
User Identification	Each message sent to the backend includes the userId and sessionId for correct message attribution and user identification.	M
Redis Integration	Messages are temporarily stored in Redis (not MongoDB) for the duration of the session to support real-time chat functionality.	H
WebSocket Connection (Frontend)	User connects to the WebSocket session upon being redirected to the collaboration page.	H
Session Information	Session information (session members, chat messages) is managed by the SessionContext.tsx component.	H
Message Sending and Updating	Users can send a message using the handleSendMessage function, which emits a "chatSendMessage" event to the backend with necessary data. After the backend processes the message, the frontend updates the message status (sent, failed) accordingly.	H
Rejoining Session	User’s session information (avatars, prior messages) is updated when they refresh or rejoin the session.	M
Chat UI	Chat interface is responsive and rendered using CSR and SSR to optimize performance and maintainability.	H

N3: Code Execution

Functional Requirement	Acceptance Criteria	Priority
N3. Code Execution
Code Execution Processing	Backend validates incoming code execution requests, accepting parameters: code, language, input, and timeout. Ensures execution completes within the specified timeout and captures output, error details, and runtime.	H
Secure Execution Environment	Each code execution request is run in an isolated Docker container to ensure security. Limits are set on memory (500 MB) and CPU (1 CPU per container) to prevent resource exhaustion attacks.	H
Error Handling and Output	If execution fails, error details (stderr) are captured and returned in the response. Each test case runs independently, so one failure does not affect the execution of other test cases.	M
Trigger Code Execution (Frontend)	Adds a submit button to the coding interface, allowing users to execute their code. Button triggers a backend request to the code-execution service with the required parameters.	H
Display Execution Results	Displays the code output, error messages, and runtime metrics in a structured format. Includes indicators for pass/fail status for each test case.	H
Test Case Orchestration	Collaboration service retrieves test cases from the question service and sends them to the code-execution service. Executes all test cases concurrently using Promise.all and aggregates results.	M
Real-Time Execution Feedback	Notifies users in the session when code execution is in progress and upon completion. Displays execution results in real-time via WebSocket updates from the collaboration service.	M

N4. Syntax Highlighting

Functional Requirement	Acceptance Criteria	Priority
N4. Syntax Highlighting
Language Support	Highlighting should support multiple programming languages.	H
Dynamic Updates	Syntax highlighting should update dynamically as users type or edit the code.	H
Language Detection	Auto-detect the language or allow manual selection for syntax highlighting.	M
Code Elements	Ensure correct highlighting of code elements like keywords, operators, and strings in different colors.	L

N6. Generative AI

Functional Requirement	Acceptance Criteria	Priority
N6. Generative AI
Code Review Processing	Backend validates and processes incoming code snippets, while adding extra metadata to facilitate prompt effectiveness.	H
Structured Response Generation	Generates structured responses in JSON format, separating explanatory text from code correction snippets.	H
Response Formatting	Sends formatted feedback to the frontend, ensuring distinct fields for explanatory text and syntax-highlighted code.	H
Trigger Code Review (Frontend)	Adds a button to the main coding interface that allows users to initiate an AI-powered code review.	H
Response Display	A panel is displayed to show the code review response in a clear and readable format.	H
Segregation of Response	Explanatory text and code suggestions are separated using different display strategies.	L
Real-Time Feedback Synchronization	Ensure fast and seamless feedback integration from backend to frontend, with a response target time of less than 10 seconds to maintain usability.	M

N7. Cloud Deployment

Functional Requirement	Acceptance Criteria	Priority
N7. Cloud Deployment
Setup Backend Services in GKE	All backend services are successfully deployed within the GKE cluster and can enter Running status. No k8 deployment or service terminated unexpectedly.	H
Service Discovery within Cluster	Services can discover other services required for its operations through defined service names. Services can complete operations that require requests sent and responses received from other services.	H
Ingress and Load Balancer	Configure Google Cloud Load Balancer routes external traffic to Ingress, which directs traffic to the appropriate backend service. Ingress and Load Balancer are correctly configured to handle HTTP and WebSocket connections.	M
Redis for Pub/Sub Service	Ensure redis cache is accessible to matching-service and collaboration-service for pub/sub mechanism.	H
Frontend Deployment on Vercel	The frontend is successfully deployed and accessible to end-users via Vercel. Initial load times under 10 seconds to ensure seamless access to the application.	H
Frontend Access to Backend APIs	Frontend can successfully make authenticated requests to backend REST APIs via JWT tokens. Frontend can establish and maintain WebSocket connections for real-time interactions with backend services, allowing for data updates and interactive features.	H
MongoDB Atlas Connectivity	All relevant services (e.g., user-service, question-service, collaboration-service) can read and write to MongoDB Atlas. Data consistency is maintained across all services interacting with MongoDB Atlas.	H...

Milestone-D5

Milestone 5 (#96)

* Add base code for collaboration service

* Added additional services for collaboration and code improvements

* Add basic collab page with resizeable panels

* Add collab-test page component for real-time collaboration

* Add capturing of selection in onInputCapture function

* Add matching history

* Integrate ide in collaboration page

* Fix lint errors for collaboration page

* Add server.js for Socket.io and YJS integration

* Basic collab editor function done

* Remove unecessary dep in useCallback

* Add monaco editor and y-websocket dependencies

* Add MonacoEditor component for collaborative code editing

* Add cursor indicators for collaboration ide

* Add dracula theme for monaco ide

* Collab-test (to be removed)

* Add todo

* Add subscribe button

* Refactor async function to fetch and display question (temp)

* Add CollaborativeEditor and InjectableCursorStyles components

* Get user and add todo

* Refactor matching logic (#104)

* Implement y-websocket and host it as a separate gateway (#101)

* Refactor code structure for collab to maintain consistency

* Adding a new yjs ws gateway

* Update merge error

* Attempt to create yjs gateway

* Remove yjs in nestjs

* Implement y-websocket as service

* Ms5 jared/refactor matching (#102)

* Add base code for collaboration service

* Added additional services for collaboration and code improvements

* Add matching history

* Refactor matching logic

---------

Co-authored-by: Evan Yan <[email protected]>

* Revert "Ms5 jared/refactor matching (#102)" (#103)

This reverts commit ef073565295c5fce8957404961346d480c23cad1.

---------

Co-authored-by: Jajabonks <[email protected]>

* Add new features and update layout in collaboration page

* Improve error handling for question creation/editing

* Update UI components in Chatbox and DescriptionTabContent

* Add y-utility package dependency

* Add useYjsStore custom hook for syncing with Yjs store

* Update CollaborativeWhiteboard to use our own yjs backend

* Refactor cursor styles and WebSocket connection in Editor

* Fix build errors

* Update default socket URLs in collaborative editor and whiteboard components

* Add cursorColors.ts with array of colors and getRandomColor() function

* Use random color for the cursors

* Implement get collab session (#105)

* Implement get collab session

* Remove unused schema

* Check session status before returning session details

* Patch: Connect collab message with gateway

* Add get question by ID endpoint

* Fix get question by id endpoint

* Reorder setupWSConnection to fix sync issues

* Update collaboration page to fetch session info before rendering

* Refactor code for passing sessionId to editor components

* Create SessionInfo schema for storing session details

* Add getSessionInfo function to collaborationService

* Add redirect user to collaboration page

* Setup y-mongo db provider (#106)

* Patch import error
:

* fix get question by id endpoint

* Update CreateQuestionModal.tsx with quill editor

* Update EditQuestionModal.tsx to include quill functionalities

* Update DescriptionTabContent.tsx to display updated description format

* Update pages to display correct question for collab session

* Add QuestionSchema parsing and update DescriptionTabContent

* Quill (#109)

* Update CreateQuestionModal.tsx with quill editor

* Update EditQuestionModal.tsx to include quill functionalities

* Update DescriptionTabContent.tsx to display updated description format

* Update pages to display correct question for collab session

* Add QuestionSchema parsing and update DescriptionTabContent

---------

Co-authored-by: shavonneg <>

* Fix build errors and eslint errors

* Remove test server file

* Remove duplicate QuestionTabPanel component

* Add env file to fe

---------

Co-authored-by: Jajared <[email protected]>
Co-authored-by: jmsandiegoo <[email protected]>
Co-authored-by: Rick <[email protected]>
Co-authored-by: Jajabonks <[email protected]>
Co-authored-by: shavonneg <>

Milestone-D4

New Features

Message Queues with Redis

Redis Pub/Sub Implementation:

• The backend now integrates Redis as a message queue using the pub/sub pattern to manage events and communication for matching events.
• Channels used include:
  • userChannel: Used to keep track of users in the matching queue.
  • matchChannel: Used for notifying matched users.
  • timeoutChannel: Used for notifying users who have been timed out.

Matching Service

• Websocket namespace /match exposed via Socket.IO to handle matching service
  • Accessible via ws://localhost:4000/match?userId=<USER_ID>
• The WebSocket now enforces that only valid userIds (based on Mongoose validation) are allowed to connect.
• All WebSocket payloads that involve a userId must match the userId used during the connection handshake.
• A single userId can only be used to establish one connection to the /match namespace.

Summary of Updated Events

Event Type	Event Name	Payload/Response	Description
Backend Listens to	findMatch	{ userId: string, selectedTopic: string[], selectedDifficulty: string }	Triggered when a user requests to find a match.
	cancelMatch	{ userId: string }	Triggered when a user cancels their match request.
	acceptMatch	{ userId: string, matchId: string }	Triggered when a user accepts a match they have received.
	declineMatch	{ userId: string, matchId: string }	Triggered when a user declines a match they have received.
Backend Emits	matchRequested	{ message: string }	Sent to the user after they successfully request a match.
	matchCancelled	{ message: string }	Sent when a user cancels their match request or declines a match.
	matchFound	{ message: string, matchUserId: string, matchId: string }	Sent to both users when a match is found for them.
	matchAccepted	{ message: string }	Sent to a user who accepts a match while waiting for the other user to accept.
	matchDeclined	{ message: string }	Sent to the other user when one user declines the match.
	matchConfirmed	{ message: string, sessionId: string }	Sent to both users when both have accepted the match, and a session is created.
	matchError	{ message: string }	Sent to a user when an error occurs during the match request, acceptance, or cancellation process.
	matchTimeout	{ message: string, timedOutUserId: string }	Sent to a user when they have been timed out due to inactivity or no matches found.
	exception	{ message: string }	Sent when an error occurs, typically during connection or match operations.

Key Updates

Centralised Env Configuration

• Added a new config object for each service in configs/env.config.ts to centralise environment variables importing and error checking.

Docker Compose Update

• Added a new matching-service to the docker-compose.yml file

Milestone-D3

Merge pull request #75 from CS3219-AY2425S1/ms3-shavonne/docker-fix

Remove env_file from frontend docker-compose.yml