Task: API endpoints for Achievement System For Gaming Stats #108
Description
Task: API endpoints for Achievement System For Gaming Stats
🚀 Create API endpoints for achievement system that tracks milestones related to Pomodoro sessions, pet collection, and pet evolution, awarding students with achievements as they meet specific criteria.
Is your task related to existing implementation?
🔹 Yes, it is dependent on the models in Issue #107.
❗ Design Philosophy
Click for more details
🔸 Fat Model, Skinny View Approach:
- Fat Model:
- The model in our application acts as the "brain" and is responsible for all business logic and operations. This includes tasks such as calculations, data transformations, and handling complex queries. All logic related to how data should behave (e.g., filtering, sorting, validations) should be placed here.
- Initially, business logic is written directly in the model. But it should be later refactored (see section: Refactoring Business Logic Through Managers for more details).
- Skinny View:
- The view is kept lightweight and focused on its main responsibility: handling the HTTP request and preparing the data for display. The view acts as the "muscle" that collects the required data from the model and returns it to the frontend (ReactJS) via REST API endpoints.
- Views should never contain business logic or complex data manipulation. Instead, they should call predefined methods from the model to gather the necessary information and pass it to the frontend.
🔸 Refactoring Business Logic Through Managers
To ensure clean, maintainable code, we follow a process where we initially write business logic directly within the model.
-
Write Business Logic in the Model:
- Start by writing the necessary logic directly in the model. This is where we define fields, methods, and the core business logic related to the model’s data.
- While this helps quickly implement functionality, it can cause models to become bloated if the logic is too complex.
-
Refactor into Managers:
- Once the logic is functional, it’s refactored into managers.py. The manager organizes common queries and operations, providing reusable methods for interacting with the model’s data.
- Instead of having complex queries or business logic directly in the model, the manager handles the intricacies, making the model file more readable and focused on the data structure.
- model.py uses the refactored logic from managers.py
-
Use Querysets for Complex Queries (Optional):
- For complex queries or reusable logic (such as filtering, ordering, and complex database joins), custom querysets are defined in querysets.py.
- This separation helps keep the model clean, while the manager and queryset handle the more intricate operations.
Describe the solution you'd like
✅ Create API Endpoints for achievement tracking:
-
GET /api/achievements/: List all available achievements.
-
POST /api/student_achievements/: Award an achievement to a student based on progress.
-
GET /api/student_achievements/{student_id}/: Get all achievements unlocked by a student.
-
PATCH /api/student_achievements/{id}/: Update the progress of a specific achievement.
Tasks Breakdown (if applicable)
📋 If this feature involves multiple steps, list them here:
-
Step 1
- Create API endpoints for achievements and student achievement tracking.
-
Step 2
- Create unit tests
Additional Context
📌 Include relevant information such as:
- Rough Model Diagram (Not 100% accurate but provides general idea)
Resources
🔗 Links to related documentation, GitHub discussions, or external references.
- Example of API Endpoints Setup (following our design philosophy)
- Django Documentation for Handling HTTP Responses
- Example of API Endpoints being set up
- Overview of CRUD
Priority & Impact
⚡ How urgent or impactful is this feature?
- Medium (important but not urgent)