Issue feat PS-3869:Change endPoints of middlewear APIs to Interface endpoint #681
Conversation
WalkthroughMultiple service files have been updated to change the API endpoint URLs. The previous endpoints using prefixes such as "/user/v1/", "/api/v1/", and "/v1/tracking" have been replaced with new paths beginning with "/interface/v1/". In addition, the AttendanceService now includes a "context" property ("cohort") in request payloads, and a few functions in CohortServices and MyClassDetailsService have had their error propagation adjusted by commenting out "throw error" statements. Overall, the changes affect how the services interact with the backend without altering the core logic or response handling. Changes
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (5)
src/services/TrackingService.ts (1)
21-30: Update getContentTrackingStatus endpoint for consistency.While createContentTracking has been updated to use
/interface/v1/, getContentTrackingStatus still uses the old/v1/prefix. This inconsistency should be addressed.export const getContentTrackingStatus = async (reqBody: ContentStatus) => { - const apiUrl: string = `${process.env.NEXT_PUBLIC_MIDDLEWARE_URL}/v1/tracking/content/search/status`; + const apiUrl: string = `${process.env.NEXT_PUBLIC_MIDDLEWARE_URL}/interface/v1/tracking/content/search/status`; try { const response = await post(apiUrl, reqBody); return response?.data; } catch (error) { console.log(error); throw error; } };src/services/CreateUserService.ts (2)
19-28: Improve type safety by replacinganywith proper interfaces.The functions use
anytype which reduces type safety. Consider creating proper interfaces for the request and response data.+interface UserData { + // Add relevant fields based on actual data structure +} + +interface UserResponse { + // Add relevant fields based on actual response structure +} + -export const createUser = async (userData: any): Promise<any> => { +export const createUser = async (userData: UserData): Promise<UserResponse> => {Also applies to: 30-39, 41-50
47-49: Inconsistent error handling in createCohort function.The error is logged but not thrown, unlike other functions. This inconsistency could lead to silent failures.
console.error('error in getting cohort list', error); - // throw error; + throw error;src/services/CohortServices.ts (2)
26-27: Standardize error handling across functions.Some functions throw errors while others suppress them with comments. This inconsistency makes error handling unpredictable for consumers.
- // throw error; + throw error;Also applies to: 60-61
94-97: Fix inconsistent return type in getCohortSearch error handler.The function returns response?.data on success but returns the error object directly in the catch block, creating inconsistent return types.
} catch (error) { console.error('Error in searching Cohorts', error); - return error; + throw error; }
🧹 Nitpick comments (8)
src/services/AcademicYearService.ts (1)
3-11: Consider improving error handling.The function swallows errors by not rethrowing or returning them, which could make debugging harder. Consider either rethrowing the error or returning it to maintain consistent error handling across services.
export const getAcademicYear = async (): Promise<any> => { const apiUrl: string = `${process.env.NEXT_PUBLIC_MIDDLEWARE_URL}/interface/v1/academicyears/list`; try { const response = await post(apiUrl,{}); return response?.data?.result; } catch (error) { console.error('error in getting academicYearId', error); + return error; } };src/services/EventService.ts (2)
24-26: Update error message in createEvent.The error message "error in getting event List Service list" is incorrect for the createEvent function context.
} catch (error) { - console.error('error in getting event List Service list', error); + console.error('error in creating event', error); return error; }
39-40: Update error message in editEvent.The error message "error in getting event List Service list" is incorrect for the editEvent function context.
} catch (error) { - console.error('error in getting event List Service list', error); + console.error('error in editing event', error); return error; }src/services/ProfileService.ts (2)
13-17: Consider using RestClient for consistency.The getUserId function uses axios directly while other functions use the RestClient. Consider using the RestClient's get method for consistency.
- const response = await axios.get(apiUrl, { - headers: { - Authorization: `Bearer ${token}`, - }, - }); + const response = await get(apiUrl);
40-54: Standardize error handling in getUserDetails.The error handling approach differs from editEditUser. Consider throwing the error for consistency.
} catch (error) { console.error('error in fetching user details', error); - return error; + throw error; }src/services/CreateUserService.ts (1)
25-25: Fix incorrect error messages in console.error.The error messages don't match the context of their respective functions:
- createUser: "error in getting cohort list"
- userNameExist: "error in getting in userNme exist" (also has a typo)
- createCohort: "error in getting cohort list"
- console.error('error in getting cohort list', error); + console.error('Error creating user', error);Also applies to: 36-36, 47-47
src/services/LoginService.ts (1)
95-109: Remove commented out code.Dead code should be removed instead of being commented out. If needed, it can be retrieved from version control.
src/services/AttendanceService.ts (1)
13-164: Remove commented-out code.Large blocks of commented-out code should be removed as they can be retrieved from version control if needed.
-// export const bulkAttendance = async ({ -// attendanceDate, -// contextId, -// userAttendance, -// }: BulkAttendanceParams): Promise<any> => { ... -// };
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
src/services/AcademicYearService.ts(1 hunks)src/services/AssesmentService.ts(3 hunks)src/services/AttendanceService.ts(4 hunks)src/services/CohortServices.ts(5 hunks)src/services/CreateUserService.ts(3 hunks)src/services/EventService.ts(3 hunks)src/services/FormService.ts(1 hunks)src/services/LoginService.ts(6 hunks)src/services/ManageUser.ts(4 hunks)src/services/MyClassDetailsService.ts(3 hunks)src/services/NotificationService.ts(4 hunks)src/services/ProfileService.ts(3 hunks)src/services/TrackingService.ts(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- src/services/FormService.ts
- src/services/AssesmentService.ts
🔇 Additional comments (7)
src/services/AcademicYearService.ts (1)
4-4: LGTM! URL change aligns with the interface endpoint migration.The endpoint update from
/user/v1/academicyears/listto/interface/v1/academicyears/listis consistent with the PR objective.src/services/ManageUser.ts (1)
13-13: LGTM! Well-structured code with proper typing and consistent error handling.The endpoint URL changes are consistent, and the code maintains good practices:
- Uses TypeScript interfaces for type safety
- Consistent error handling across functions
- Appropriate HTTP methods for different operations
Also applies to: 27-27, 41-41, 55-55
src/services/NotificationService.ts (1)
14-14: LGTM! API endpoint URLs have been updated consistently.The changes align with the PR objective of updating middleware API endpoints to use the
/interface/v1/prefix.Also applies to: 93-93, 110-110, 127-127
src/services/MyClassDetailsService.ts (2)
14-14: LGTM! API endpoint URLs have been updated consistently.The changes align with the PR objective of updating middleware API endpoints to use the
/interface/v1/prefix.Also applies to: 37-37, 99-99
47-48: Review error handling strategy.Commenting out error throwing changes the error propagation behavior. This might prevent upstream error handlers from properly handling API failures.
Please verify:
- Are there any error boundaries or global error handlers that depend on these errors being propagated?
- How should API failures be handled by the calling code?
Also applies to: 135-136
src/services/AttendanceService.ts (2)
172-172: LGTM! API endpoint URLs have been updated consistently.The changes align with the PR objective of updating middleware API endpoints to use the
/interface/v1/prefix.Also applies to: 192-192, 213-213, 311-311
178-178: LGTM! Context property added consistently.The
context: "cohort"property has been added consistently to all attendance-related requests.Also applies to: 199-199, 214-214, 232-232, 245-245, 259-259, 272-272, 286-286, 301-301, 312-312
| export const resetPassword = async ( | ||
| newPassword: any): Promise<any> => { | ||
| const apiUrl: string = `${process.env.NEXT_PUBLIC_MIDDLEWARE_URL}/user/v1/reset-password`; | ||
| const apiUrl: string = `${process.env.NEXT_PUBLIC_MIDDLEWARE_URL}/interface/v1/user/reset-password`; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve type safety by adding proper interfaces for password-related functions.
Several functions use any type which reduces type safety:
- resetPassword
- forgotPasswordAPI
- resetPasswordLink
+interface PasswordReset {
+ newPassword: string;
+}
+interface ForgotPassword {
+ newPassword: string;
+ token: string;
+}
+interface PasswordResetLink {
+ username: string;
+}
-export const resetPassword = async (newPassword: any): Promise<any> => {
+export const resetPassword = async (newPassword: PasswordReset): Promise<void> => {Also applies to: 64-66, 77-79
Summary by CodeRabbit
Chores
• Updated backend integrations across academic data, assessments, attendance, cohorts, user management, events, notifications, profiles, and content tracking for enhanced stability and consistency.
• Improved attendance operations by including additional contextual details for better data accuracy.
Refactor
• Optimized error handling in several modules to ensure a smoother and more reliable user experience.
These behind‐the‑scenes improvements help provide a more consistent and dependable platform experience.