improvement(hygiene): refactored routes to be more restful, reduced code surface area and removed redundant code

[waleedlatif1]

• improvement(invitations): consolidate invite-error and invite pages, made API endpoints more restful and reduced code surface area for invitations by 50%
• refactored logs API routes
• refactor rate limit api route, consolidate usage check api endpoint
• refactored chat page and invitations page

Summary

refactored routes to be more restful, reduced code surface area and removed redundant code

• consolidated pages, routes that did the same thing
• refactored routes to be more restful so its easy to manage
• refactored some directories to follow established practices
• added enum for invitations

Type of Change

• Other: refactor

Testing

Unit tests, tested manually. No functional changes.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
sim	Ready	Preview	Comment	Sep 2, 2025 3:57am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Skipped			Sep 2, 2025 3:57am

[greptile-apps]

Greptile Summary

This PR implements a comprehensive refactoring to consolidate and streamline invitation handling, API endpoints, and chat components. The changes introduce several key architectural improvements:

API Refactoring: Multiple endpoints have been consolidated to follow RESTful principles. The /api/usage-limits endpoint was renamed to /api/usage and now handles both user and organization contexts through query parameters. The /api/users/rate-limit endpoint was moved to /api/users/me/rate-limit to better represent current user resources. Several invitation-specific endpoints were consolidated into parameterized routes that handle multiple operations through HTTP methods rather than separate action-based URLs.

Invitation System Consolidation: The invite-error and invite pages have been merged into a unified invitation flow. The old separate error page (/invite/invite-error/) has been removed, with error handling now consolidated into the main invite component using reusable InviteStatusCard and InviteLayout components. A new database enum workspace_invitation_status was added with values ['pending', 'accepted', 'rejected', 'cancelled'] to provide stronger typing and data integrity.

Provider Store Unification: The separate useOllamaStore and useOpenRouterStore have been consolidated into a single useProvidersStore that manages multiple providers through a unified interface. This eliminates code duplication and provides a consistent pattern for managing provider models across the application.

Chat Component Restructuring: Chat-related components have been moved from subdomain-specific directories (chat/[subdomain]/components/) to a shared chat/components/ structure. This consolidation removes the need for subdomain-specific component variations while maintaining the ability to handle different subdomains through props.

File Organization: Several utility files have been extracted and consolidated, including the creation of component index files following barrel export patterns and the extraction of shared utilities like getErrorMessage into dedicated files.

These changes significantly reduce the codebase surface area by approximately 50% for invitation-related functionality while maintaining backward compatibility and the same user experience. The refactoring follows established architectural patterns and improves maintainability through better separation of concerns and reduced code duplication.

Confidence score: 4/5

• This PR requires careful review due to the extensive architectural changes affecting multiple core systems
• Score reflects the complexity of consolidating invitation flows, provider stores, and API endpoints while maintaining functionality
• Pay close attention to database migration files, API endpoint consolidation, and provider store refactoring

Context used:

Context - When defining properties for components, use a dedicated config file (.ts) for configuration and keep rendered components in their respective component files. (link)
Context - Group optional parameters into an options object for better maintainability when defining functions or methods. (link)
Context - If a switch statement is large and handles multiple cases, extract each case into separate functions for better maintainability. (link)
Context - Avoid using type assertions to 'any' in TypeScript. Instead, ensure proper type definitions are used to maintain type safety. (link)
Context - Use established path alias patterns instead of deeply nested relative import paths. (link)

_{70 files reviewed, 7 comments}

_{Edit Code Review Bot Settings | Greptile}