Merge branch 'dev' into delete-child-comments

Author: edupro26

README.md

@@ -33,7 +33,7 @@ We also made available a [Postman collection](https://grupo-8-0813.postman.co/wo
 
 ## 📦 Application Architecture
 
-![application architecture](./docs/images/architecture.png)
+![application architecture](./docs/images/application-architecture.png)
 
 ## 🔍 Development Phases
 

docs/images/application-architecture.png

@@ -1,3 +1,3 @@
 ## 🔍 Phase 10 - Final Report
 
-TODO
+The project final report can be found [here](../report/threadit_grupo8_final_report.pdf).

docs/images/architecture.png

@@ -3,60 +3,42 @@
 ### 📌 Functional Requirements
 
 #### 🌍 Communities
-- **FR3.1:** The system should allow users to retrieve a list of communities.
-- **FR3.2:** The system should allow users to retrieve a list of communities they are members of.
-- **FR3.3:** The system should allow users to retrieve a list of communities another user is a member of.
-- **FR3.4:** The system should allow users to view the details of a specific community, including its name, description, icon, owner, and creation date.
-- **FR3.5:** The system should allow users to create a new community by providing a name and description.
-- **FR3.6:** The system should allow community owners to update the community name.
-- **FR3.7:** The system should allow community owners to update the community description.
-- **FR3.8:** The system should allow community owners to delete the community.
-- **FR3.9:** The system should allow community owners to update the community icon by uploading an image file.
-- **FR3.10:** The system should allow users to join a community.
-- **FR3.11:** The system should allow users to leave a community.
-- **FR3.12:** The system should allow users to retrieve a list of members in a specific community.
+- The system should allow to list all communities, optionally by name, offset and limit.
+- The system should allow to create a new community with a given name.
+- The system should allow to get a community by id, with its name and number of threads.
+- The system should allow to update a community's name or number of threads by id.
+- The system should allow to delete a community by id.
 
 #### 📝 Threads
-- **FR4.1:** The system should allow users to retrieve a list of threads.
-- **FR4.2:** The system should allow users to retrieve a list of threads in a specific community.
-- **FR4.3:** The system should allow users to retrieve a list of threads they have published.
-- **FR4.4:** The system should allow users to retrieve a list of threads they have published in a specific community.
-- **FR4.5:** The system should allow users to retrieve a list of threads published by another user.
-- **FR4.6:** The system should allow users to retrieve a list of threads published by another user in a specific community.
-- **FR4.7:** The system should allow users to view the details of a specific thread, including its title, content, author, creation date, update date, and associated community.
-- **FR4.8:** The system should allow users to create a new thread by providing a title, content, and selecting a community.
-- **FR4.9:** The system should allow users to update the title of a thread they have published.
-- **FR4.10:** The system should allow users to update the content of a thread they have published.
-- **FR4.11:** The system should allow users to delete a thread they have published.
-- **FR4.12:** The system should allow community owners to delete any thread in their community.
+- The system should allow to list all threads, optionally by community id, title, offset, limit and sort order.
+- The system should allow to create a new thread with a title and content in a specific community.
+- The system should allow to get a thread by id, with its title, content, community id, upvotes, downvotes and number of comments.
+- The system should allow to update a thread's title, content, votes or number of comments by id.
+- The system should allow to delete a thread by id.
 
 #### 💬 Comments
-- **FR5.1:** The system should allow users to retrieve a list of comments for a specific thread.
-- **FR5.2:** The system should support pagination for comment retrieval.
-- **FR5.3:** The system should allow authenticated users to create a new comment for a thread.
-- **FR5.4:** The system should allow users to retrieve the details of a specific comment.
-- **FR5.5:** The system should allow authenticated users to update their own comments.
-- **FR5.6:** The system should enforce authorization checks to prevent users from modifying or deleting comments they do not own.
-- **FR5.7:** The system should allow authenticated users to delete their own comments.
-- **FR5.8:** The system should allow users to reply to existing comments.
-- **FR5.9:** The system should ensure that replies are correctly linked to their parent comment.
+- The system should allow to list all comments, optionally by thread id, offset, limit and sort order.
+- The system should allow to create a new comment with content in a thread or another comment.
+- The system should allow to get a comment by id, with its content, upvotes, downvotes, parent id, parent type (thread or comment) and number of replies.
+- The system should allow to update a comment's content, votes or number of replies by id.
+- The system should allow to delete a comment by id.
 
 #### ⬆️ Voting System
-- **FR6.1:** The system should allow authenticated users to upvote or downvote a thread.
-- **FR6.2:** The system should allow authenticated users to upvote or downvote a comment.
-- **FR6.3:** The system should allow authenticated users to change or remove their vote on a thread or comment.
+- The system should allow to upvote or downvote a thread.
+- The system should allow to upvote or downvote a comment.
+- The system should allow to change or remove vote on a thread or comment.
 
 #### 🔎 Search & Discovery
-- **FR9.1:** The system should allow users to search for threads by keyword.
-- **FR9.2:** The system should allow users to search for communities by keyword.
-- **FR9.3:** The system should allow users to search for other users by keyword.
-- **FR9.4:** The system should allow users to search all content by keyword.
-- **FR9.5:** The system should support pagination for search results.
-- **FR9.6:** The system should allow users to sort search results by date or popularity.
+- The system should allow to search for threads by keyword.
+- The system should allow to search for communities by keyword.
+- The system should allow to search for both by keyword.
+- The system should support pagination (offset and limit) for searches.
+- The system should support sort order () for searches.
 
 #### 🔗 Microservices Communication
-- **FR10.1:** The system should enforce that all inter-service communication between microservices uses gRPC.
+- The system should enforce that all inter-service communication between microservices uses gRPC.
+- The system should expose a REST API for external clients to interact with the system.
 
 ### 📦 Application Architecture
 
-![Application architecture](../images/architecture.png)
+![Application architecture](../images/application-architecture.png)

docs/images/technical-architecture.png

@@ -2,13 +2,10 @@
 
 ## 1. Planned Improvements
 
-### 1.1 Ingress/API Gateway Configuration
+### 1.1 API Gateway Configuration
 
-Currently, we are using Traefik with a basic IngressRoute and minimal configuration. To improve flexibility and take advantage of Kubernetes-native features, we will explore two alternatives:
-
-- **Kubernetes Ingress with Traefik:** This allows using standard Ingress resources with Traefik's CRDs for fine-grained traffic routing, TLS termination, and middleware chaining.
-
-- **Kubernetes Gateway API:** A more expressive and extensible alternative to the Ingress API, which decouples traffic routing from infrastructure. We'll experiment with it alongside Traefik's Gateway API support to modernize our networking layer.
+The application will use a Traefik instance installed and configured via Helm. 
+An IngressRoute and some Middlewares will be defined to ensure that Traefik routes the incoming requests to the gRPC Gateway.
 
 ### 1.2 Liveness and Readiness Probes
 To improve fault tolerance and enable better self-healing behavior in Kubernetes, we will define:
@@ -22,9 +19,6 @@ We will benchmark services to determine ideal values for:
 * **CPU and memory resource requests/limits**.
 * **Horizontal Pod Autoscaling (HPA)** thresholds based on real traffic patterns to ensure scalability.
 
-### 1.4 Authentication & Authorization with Keycloak
-We will introduce authentication and authorization by integrating [Keycloak](https://www.keycloak.org/) as the Identity Provider. Keycloak will manage user sessions, tokens (OIDC) and Role-Based Access Control (RBAC) across the services.
-
 ### 1.5 Secret management
 
 To further improve security we will explore Google Secret Manager for managing sensitive configuration data such as API keys, credentials and tokens. This approach provides:
@@ -49,18 +43,20 @@ A continuous integration and deployment (CI/CD) pipeline will be implemented usi
 | --------------- | -------------------------------------------------------------------------- |
 | Scalability     | Use HPA to autoscale services based on CPU usage.                          |
 | Availability    | Configure liveness/readiness probes and multiple replicas where necessary. |
-| Security        | Enforce authentication and authorization via Keycloak.                     |
 | Maintainability | Implement CI/CD for consistent, automated deployments.                     |
 
 ## 3. Deployment Plan
-| Step                            | Tool/Technology       |
-| ------------------------------- | --------------------- |
-| Containerization                | Docker                |
-| Cluster Orchestration           | Kubernetes (GKE)      |
-| Ingress Management              | GKE Native Ingress    |
-| Identity and Access Management  | Keycloak (OIDC, RBAC) |
-| CI/CD                           | GitHub Actions + GKE  |
-| Autoscaling                     | Kubernetes HPA        |
+| Step                            | Tool/Technology            |
+| ------------------------------- |----------------------------|
+| Containerization                | Docker                     |
+| Cluster Orchestration           | Kubernetes (GKE)           |
+| Ingress Management              | Traefik Ingress Controller |
+| CI/CD                           | GitHub Actions             |
+| Autoscaling                     | Kubernetes HPA             |
 
 ## 4. Architecture Diagram
-![application architecture](../images/architecture.png)
+![Application architecture](../images/application-architecture.png)
+
+## 5. Technical Architecture
+
+![Technical architecture](../images/technical-architecture.png)

docs/phases/phase10.md

@@ -1,3 +1,3 @@
 ## 🔍 Phase 9 - System Testing
 
-TODO
+This phase can be found under the chapter 8 of the final [report](../report/threadit_grupo8_final_report.pdf).