Description
Several list endpoints return all records without pagination: GET /api/equipment, GET /api/maintenance, GET /api/orders, GET /api/supplier/orders, GET /api/shipments/order/{orderId}. As the database grows, these will return increasingly large JSON payloads, consume excessive memory, and eventually cause OutOfMemoryError crashes. Only GET /api/equipment/page exists, and there's no consistency in pagination interfaces across endpoints.
Proposed Solution
Backend Changes
-
Add Pageable parameter support to each endpoint:
- GET /api/equipment: Add Pageable param, return Page
- GET /api/maintenance: Add Pageable param, return Page
- GET /api/orders: Add Pageable param + filters
- GET /api/shipments/*: Add Pageable param
-
Create a standard PagedResponse DTO with content, page, size, totalElements, totalPages, first, last
-
Add @PageableDefault with sensible sort ordering on all endpoints
-
Add pagination to maintenance filter queries (currently accepts technicianId, status, priority but no pagination)
Frontend Changes
- Update EquipmentList with page navigation, page size selector, and X of Y display
- Add page/size/sort params to getAllEquipment() service call
- Create reusable Pagination component: src/components/common/Pagination.jsx
- Apply to MaintenanceSchedule, OrdersList, and TaskList
Files to Modify (20+ files)
- Backend: EquipmentController, MaintenanceController, OrderController, ShipmentTrackingController
- Backend: EquipmentService, MaintenanceService, OrderService
- Backend: EquipmentRepository, MaintenanceTaskRepository, EquipmentOrderRepository
- Backend: New PagedResponse DTO
- Frontend: EquipmentList.jsx, MaintenanceSchedule.jsx, OrdersList.jsx, TaskList.jsx
- Frontend: EquipmentService.js, MaintenanceService.js, OrderService.js
- Frontend: New Pagination.jsx component
Expected Impact
- Prevents OOM crashes at scale
- Reduces API response times by 10-100x for large datasets
- Consistent UX across all list views
- Mobile-friendly with smaller payloads
Difficulty
Medium-Hard
Description
Several list endpoints return all records without pagination: GET /api/equipment, GET /api/maintenance, GET /api/orders, GET /api/supplier/orders, GET /api/shipments/order/{orderId}. As the database grows, these will return increasingly large JSON payloads, consume excessive memory, and eventually cause OutOfMemoryError crashes. Only GET /api/equipment/page exists, and there's no consistency in pagination interfaces across endpoints.
Proposed Solution
Backend Changes
Add Pageable parameter support to each endpoint:
Create a standard PagedResponse DTO with content, page, size, totalElements, totalPages, first, last
Add @PageableDefault with sensible sort ordering on all endpoints
Add pagination to maintenance filter queries (currently accepts technicianId, status, priority but no pagination)
Frontend Changes
Files to Modify (20+ files)
Expected Impact
Difficulty
Medium-Hard