Backend mid-specialism weekly plan #269
+184
−15
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,25 +1,194 @@ | ||
| # Weekly Plan – Backend Project | ||
|
|
||
| This document outlines the expected weekly progress and milestones for completing the backend project. | ||
| The structure aligns with the Product Requirements Document (PRD), Shared API Contract, and Technical Specification. | ||
|
|
||
| The goal is to progressively implement a fully functional, contract-compliant API with proper documentation, testing, and deployment. | ||
|
|
||
| --- | ||
|
|
||
| ## Week 1 Sprint – Core Data Modeling (DB week 1) | ||
|
|
||
| ### Week 1 Goal | ||
|
|
||
| Design and implement the foundational database schema for users and catalog entities. | ||
|
|
||
| ### Week 1 Tasks | ||
|
|
||
| - [ ] Review the Product Requirements Document (PRD) | ||
|
Contributor
There was a problem hiding this comment. This will be part of the project docs overall so i don't think we need to call it out specifically here |
||
| - [ ] Design ERD (v1) including: | ||
| - `user` | ||
| - `{domain}_item` (e.g. `event`) | ||
| - [ ] Implement PostgreSQL schema with: | ||
| - Primary keys | ||
| - Foreign keys (where applicable) | ||
| - Proper constraints | ||
| - [ ] Add seed data for: | ||
| - At least 1 test user | ||
| - Multiple catalog items | ||
| - [ ] Implement and test basic SQL queries: | ||
| - Get all items | ||
| - Get item by ID | ||
| - [ ] Document ERD in the repository | ||
|
|
||
| ### Week 1 Outcome | ||
|
Contributor
There was a problem hiding this comment. I like the clear outcomes here, nice idea |
||
|
|
||
| - Working PostgreSQL database | ||
| - ERD v1 committed | ||
| - Seeded data available | ||
| - Catalog data queryable directly via SQL | ||
|
|
||
| --- | ||
|
|
||
| ## Week 2 Sprint – Complete Database Structure (DB week 2) | ||
|
|
||
| ### Week 2 Goal | ||
|
|
||
| Finalize database structure to support cart, checkout, and order flows. | ||
|
|
||
| ### Week 2 Tasks | ||
|
|
||
| - [ ] Extend ERD to include: | ||
| - `cart` | ||
| - `cart_item` | ||
| - `order` | ||
| - `order_item` | ||
| - [ ] Implement all foreign key relationships | ||
| - [ ] Enforce “one active cart per user” rule | ||
| - [ ] Implement SQL queries for: | ||
| - Paginated item listing (`LIMIT`, sorting) | ||
| - Cart subtotal calculation | ||
| - Order totals snapshot logic | ||
| - [ ] Update ERD (v2) | ||
| - [ ] Add seed updates if needed | ||
|
|
||
| ### Week 2 Outcome | ||
|
|
||
| - Complete database schema supporting full PRD flow | ||
| - ERD v2 finalized | ||
| - Cart and order data structures functional at SQL level | ||
|
|
||
| --- | ||
|
|
||
| ## Week 3 Sprint – Public API (NODE week 1: GET Only) | ||
|
|
||
| ### Week 3 Goal | ||
|
|
||
| Expose public catalog endpoints and implement initial API documentation. | ||
|
|
||
| ### Week 3 Tasks | ||
|
|
||
| - [ ] Set up Express application structure | ||
| - [ ] Connect application to PostgreSQL | ||
| - [ ] Implement public endpoints: | ||
| - `GET /api/{domain}` (paginated) | ||
| - `GET /api/{domain}/search` | ||
| - `GET /api/{domain}/{id}` | ||
| - [ ] Implement pagination response format: | ||
|
|
||
| ```json | ||
| { | ||
| "data": [], | ||
| "meta": { | ||
| "page": 1, | ||
| "pageSize": 20, | ||
| "totalItems": 245, | ||
| "totalPages": 13 | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| - [ ] Implement standardized error format | ||
| - [ ] Add Swagger/OpenAPI documentation for public endpoints | ||
| - [ ] Start Postman collection (public endpoints) | ||
|
|
||
| ### Week 3 Outcome | ||
|
|
||
| - Public catalog API functional | ||
| - Pagination working | ||
| - API documented via Swagger | ||
| - Postman collection includes public routes | ||
|
|
||
| --- | ||
|
|
||
| ## Week 4 Sprint – Authentication & Cart (NODE week 2: POST + Middleware) | ||
|
|
||
| ### Week 4 Goal | ||
|
|
||
| Implement authentication and protected cart functionality. | ||
|
|
||
| ### Week 4 Tasks | ||
|
|
||
| - [ ] Implement authentication endpoints: | ||
| - `POST /api/auth/signup` | ||
| - `POST /api/auth/login` | ||
| - `GET /api/auth/me` | ||
| - [ ] Implement JWT-based authentication middleware | ||
| - [ ] Protect private endpoints | ||
| - [ ] Implement cart endpoints: | ||
| - `GET /api/cart` | ||
| - `POST /api/cart/items` | ||
| - `PUT /api/cart/items/{itemId}` | ||
| - [ ] Validate request payloads | ||
| - [ ] Ensure consistent error responses | ||
| - [ ] Update Swagger documentation | ||
| - [ ] Extend Postman collection with auth + cart flows | ||
|
|
||
| ### Week 4 Outcome | ||
|
|
||
| - JWT authentication functional | ||
| - Protected routes working | ||
| - Cart can be created and modified | ||
| - Documentation updated | ||
|
|
||
| --- | ||
|
|
||
| ## Week 5 Sprint – Checkout, Orders & Deployment (NODE week 3: PUT/DELETE + Transactions) | ||
|
|
||
| ### Week 5 Goal | ||
|
|
||
| Complete private API, implement checkout transaction, and deploy. | ||
|
|
||
| ### Week 5 Tasks | ||
|
|
||
| - [ ] Implement remaining cart endpoints: | ||
| - `DELETE /api/cart/items/{itemId}` | ||
| - `POST /api/cart/checkout` (transactional) | ||
| - [ ] Implement order endpoints: | ||
| - `GET /api/orders` | ||
| - `GET /api/orders/{orderId}` | ||
| - [ ] Implement database transaction for: | ||
| - Converting active cart → order | ||
| - Creating order items | ||
| - Clearing/replacing active cart | ||
| - [ ] Finalize error handling across all routes | ||
| - [ ] Complete Swagger documentation | ||
| - [ ] Finalize Postman collection | ||
| - [ ] Deploy: | ||
| - Database | ||
| - API service | ||
| - Swagger documentation | ||
|
|
||
| ### Week 5 Outcome | ||
|
|
||
| - Fully functional contract-compliant backend | ||
| - Checkout flow transactional and stable | ||
| - Orders history available | ||
| - Swagger/OpenAPI docs accurately reflect the implemented API | ||
| - API + DB deployed | ||
| - Postman collection complete | ||
|
|
||
| --- | ||
|
|
||
| ## Final Deliverables | ||
|
Contributor
There was a problem hiding this comment. These are defined in the main project docs already, where i think they make better sense. However, i like your updates to make them more specific now we have more tangible ideas (e.g. calling out ERD documentation, Swagger etc.). So leave them here for now, and later on i will do some restructuring to make sure there is no duplication of info, and take the best versions :-) |
||
|
|
||
| By the end of Week 5, you must provide: | ||
|
|
||
| - [ ] GitHub repository | ||
| - [ ] ERD documentation | ||
| - [ ] Deployed PostgreSQL database | ||
| - [ ] Deployed API service (including working Swagger UI from the provided skeleton) | ||
| - [ ] Swagger/OpenAPI documentation updated to match your implementation | ||
| - [ ] Postman collection covering core flows | ||
|
|
||
| --- | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We haven't used the term "catalog"/"catalog entities" elsewhere in the docs yet. I suggest because right now the domain is a given (event tickets etc) that we use those terms from the PRD.
Same where you've left a {domain} placeholder below, i suggest you just fill out these placeholders with terms used in the prd already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, I thought that we give a space for a minor creativity I mean it could be travel tickets, or actual online store with products, etc.., therefore I kept a placeholder