Update use case diagrams and design patterns for authentication and API key management by mrstrange1708 · Pull Request #27 · RISHIK92/velox

mrstrange1708 · 2026-04-13T08:51:17Z

No description provided.

…ication and API key management workflows.

Copilot

Pull request overview

Updates Velox’s documentation diagrams to reflect the current authentication flows and API key management features, and to reorganize the design patterns reference.

Changes:

Refines the use case diagram to emphasize authentication + API key management and adds an internal include/extend-style flow for submissions/status.
Reorganizes the design patterns catalog by removing the Template Method section and renumbering subsequent sections.
Updates detailed use case descriptions for auth, API keys, submissions, dashboard, health, and Swagger docs.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
diagrams/07_design_patterns.md	Removes the Template Method section and renumbers later pattern sections/TOC entries.
diagrams/04_use_case_diagram.md	Replaces the multi-actor diagram with a primary-user-focused diagram and adds/updates detailed auth + API key + submission flows.

Comments suppressed due to low confidence (1)

diagrams/07_design_patterns.md:263

The Template Method Pattern section was removed above, but the document still references Template Method later in the “Summary: Pattern Map” (e.g., Template["Template Method..." ] and Strategy --> Template). Either restore the section or remove/update those later references so the design pattern catalog stays consistent.

## 8. Domain Model Pattern

**Category:** Architectural  
**Location:** `backend/judge/judge.go`

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-13T08:55:48Z

@@ -15,11 +15,10 @@ A comprehensive catalog of all **design patterns**, **architectural patterns**,
 | 5 | [Service Layer Pattern](#5-service-layer-pattern) | Architectural | `auth/service/` |
 | 6 | [Producer-Consumer Pattern](#7-producer-consumer-pattern) | Concurrency | API → Redis → Worker |


In the Table of Contents, the Producer-Consumer row links to #7-producer-consumer-pattern, but the section header is ## 6. Producer-Consumer Pattern (GitHub anchor will be #6-producer-consumer-pattern). Update the TOC links (or add explicit anchors) so they resolve correctly.

Suggested change

| 6 | [Producer-Consumer Pattern](#7-producer-consumer-pattern) | Concurrency | API → Redis → Worker |

| 6 | [Producer-Consumer Pattern](#6-producer-consumer-pattern) | Concurrency | API → Redis → Worker |

Copilot · 2026-04-13T08:55:48Z

 | 7 | [Singleton Pattern](#8-singleton-pattern) | Creational | `shared/redis/` |
-| 8 | [Template Method Pattern](#9-template-method-pattern) | Behavioral | `InterpreterStrategyManager` |
-| 9 | [Domain Model Pattern](#11-domain-model-pattern) | Architectural | `judge/` |
-| 10 | [Factory Pattern](#12-factory-pattern) | Creational | `NewDefaultRegistry()`, `NewSubmissionService()` |
-| 11 | [Decorator Pattern](#14-decorator-pattern) | Structural | Middleware wrapping |
-| 12 | [Single Responsibility Principle](#15-single-responsibility-principle-srp) | SOLID | `ResultAggregator`, separated packages |
+| 8 | [Domain Model Pattern](#11-domain-model-pattern) | Architectural | `judge/` |
+| 9 | [Factory Pattern](#12-factory-pattern) | Creational | `NewDefaultRegistry()`, `NewSubmissionService()` |
+| 10 | [Decorator Pattern](#14-decorator-pattern) | Structural | Middleware wrapping |
+| 11 | [Single Responsibility Principle](#15-single-responsibility-principle-srp) | SOLID | `ResultAggregator`, separated packages |


Several TOC entries use stale anchors after renumbering/removing sections (e.g., Singleton links to #8-singleton-pattern but header is ## 7...; Domain Model/Factory/Decorator/SRP also link to #11/#12/#14/#15... while headers are ## 8-11). This will break intra-doc navigation; update the anchors to match the current headings (or add explicit anchor tags).

Copilot · 2026-04-13T08:55:49Z

+### UC4: Create API Key
+| Field | Value |
+|-------|-------|
+| **Actor** | User |
+| **Trigger** | `POST /auth/api-keys` (requires session auth) |
+| **Flow** | 1. User provides `name`, optional `scopes` and `expires_at` <br/> 2. Default scopes: `["submit", "status"]` <br/> 3. Server generates key, stores hash in DB <br/> 4. Returns full key (shown only once), ID, and display hint |


These API key management routes are protected by the JWT RequireAuth middleware (Authorization: Bearer ), not a server-side session. Consider renaming “requires session auth” to “requires Bearer/JWT auth” here (and consistently for UC5/6/7/10/11).

Copilot · 2026-04-13T08:55:49Z

+| **Trigger** | `PATCH /auth/api-keys?id=<uuid>` (requires session auth) |
+| **Flow** | Renames an existing API key |


UC6 (Update API Key) omits that the PATCH handler expects a JSON body (e.g., { "name": "..." }) and can return 400 on invalid/missing JSON, in addition to requiring Bearer/JWT auth. Updating the trigger/flow/error cases to reflect the actual API contract would prevent confusion.

Suggested change

| **Trigger** | `PATCH /auth/api-keys?id=<uuid>` (requires session auth) |

| **Flow** | Renames an existing API key |

| **Trigger** | `PATCH /auth/api-keys?id=<uuid>` with JSON body such as `{ "name": "..." }` (requires Bearer/JWT auth) |

| **Flow** | 1. User sends the target API key ID as a query parameter and a JSON body containing the new `name` <br/> 2. Server authenticates the request using Bearer/JWT auth <br/> 3. Server validates the JSON body and `name` value <br/> 4. Server updates the existing API key name and returns the updated record |

| **Error Cases** | Missing or invalid JSON body → 400, Missing `name` → 400, Unauthorized → 401, Invalid or missing API key ID → 400/404 |

Copilot · 2026-04-13T08:55:49Z

-            UC21([Deploy Stack])
-            UC22([Run CI Tests])
+        subgraph "Documentation"
+            UC13([View Docs])


In the main use case diagram, UC13 is labeled “View Docs”, but the detailed UC13 is specifically “View Swagger Docs” with trigger GET /swagger/ (dev-only). Align the diagram label with the detailed use case to avoid ambiguity.

Suggested change

UC13([View Docs])

UC13([View Swagger Docs])

mrstrange1708 added 2 commits April 13, 2026 14:18

docs: update use case diagrams and design patterns to reflect authent…

da2e995

…ication and API key management workflows.

Merge branch 'main' of https://github.com/mrstrange1708/velox

fa955ea

Copilot AI review requested due to automatic review settings April 13, 2026 08:51

Copilot started reviewing on behalf of mrstrange1708 April 13, 2026 08:51 View session

Copilot AI reviewed Apr 13, 2026

View reviewed changes

RISHIK92 merged commit 5487a57 into RISHIK92:main Apr 13, 2026
13 of 14 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update use case diagrams and design patterns for authentication and API key management#27

Update use case diagrams and design patterns for authentication and API key management#27
RISHIK92 merged 2 commits into
RISHIK92:mainfrom
mrstrange1708:main

mrstrange1708 commented Apr 13, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 13, 2026

Uh oh!

Copilot AI Apr 13, 2026

Uh oh!

Copilot AI Apr 13, 2026

Uh oh!

Copilot AI Apr 13, 2026

Uh oh!

Copilot AI Apr 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -15,11 +15,10 @@ A comprehensive catalog of all design patterns, architectural patterns,
		\| 5 \| [Service Layer Pattern](#5-service-layer-pattern) \| Architectural \| `auth/service/` \|
		\| 6 \| [Producer-Consumer Pattern](#7-producer-consumer-pattern) \| Concurrency \| API → Redis → Worker \|

	\| 6 \| [Producer-Consumer Pattern](#7-producer-consumer-pattern) \| Concurrency \| API → Redis → Worker \|
	\| 6 \| [Producer-Consumer Pattern](#6-producer-consumer-pattern) \| Concurrency \| API → Redis → Worker \|

		\| Trigger \| `PATCH /auth/api-keys?id=<uuid>` (requires session auth) \|
		\| Flow \| Renames an existing API key \|

-| **Trigger** | `PATCH /auth/api-keys?id=<uuid>` (requires session auth) |
-| **Flow** | Renames an existing API key |
+| **Trigger** | `PATCH /auth/api-keys?id=<uuid>` with JSON body such as `{ "name": "..." }` (requires Bearer/JWT auth) |
+| **Flow** | 1. User sends the target API key ID as a query parameter and a JSON body containing the new `name` <br/> 2. Server authenticates the request using Bearer/JWT auth <br/> 3. Server validates the JSON body and `name` value <br/> 4. Server updates the existing API key name and returns the updated record |
+| **Error Cases** | Missing or invalid JSON body → 400, Missing `name` → 400, Unauthorized → 401, Invalid or missing API key ID → 400/404 |

Conversation

mrstrange1708 commented Apr 13, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants