Krow/Krow-workspace
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: restructure monorepo to align with industry standards

Browse Source 
This commit restructures the monorepo to improve organization,
maintainability, and scalability. The changes include:

- Moving mobile apps from `mobile-apps/` to `apps/mobile-*`.
- Moving the web dashboard from `admin-web/` and `frontend-web/`
 to `apps/web-dashboard/`.
- Moving Firebase-related files to the root `firebase/` directory.
- Adding a `.geminiignore` file to exclude unnecessary files from
 Gemini analysis.
- Updating `.gitignore` to reflect the new structure and exclude
 sensitive files.
- Updating `codemagic.yaml` to reflect the new app locations.
- Adding a `make help` command to the root directory.
- Adding a `make install-git-hooks` command to install git hooks.
- Adding a `docs/02-codemagic-env-vars.md` file to document
 Codemagic environment variables.
- Adding a `docs/03-contributing.md` file to document
 contribution guidelines.
- Adding prototype placeholders to the internal launchpad.
- Updating the `README.md` file to reflect the new structure and
 provide updated instructions.

These changes improve the overall structure of the monorepo and
make it easier to develop, maintain, and scale the KROW Workforce
platform.
This commit is contained in:
bwnyasse
2026-01-10 22:36:29 -05:00
parent a0d820d3ce
commit 3c0488576b
20 changed files with 396 additions and 410 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
internal/launchpad/assets/documents/legacy/staff-mobile-application/architecture.md
View File

@@ -85,36 +85,3 @@ The application uses the **Bloc** library for state management.
2. **Logic:** The `ShiftsBloc` requests a list of shifts.
3. **Backend:** The use case calls the `ShiftsRepository`, which sends a `getShifts` query to the GraphQL server. The server fetches the shifts from Firestore.
4. **Response:** The GraphQL server returns the list of shifts, which is then displayed on the UI.
## G. Replacing or Plugging in a New Backend: Considerations & Recommendations
This section provides guidance on how to replace the current GraphQL + Firebase backend with a different solution (e.g., REST, Supabase, Hasura).
### Tightly Coupled Components
- **Data Layer:** The current `ApiProvider` implementations are tightly coupled to the GraphQL API.
- **Authentication:** The authentication flow is tightly coupled to Firebase Auth.
- **DTOs:** The data transfer objects are generated based on the GraphQL schema.
### Abstraction Recommendations
To make the architecture more backend-agnostic, the following components should be abstracted:
- **Repositories:** The repository interfaces in the Domain Layer should remain unchanged. The implementations in the Data Layer will need to be rewritten for the new backend.
- **Services:** Services like authentication should be abstracted behind an interface. For example, an `AuthService` interface can be defined in the Domain Layer, with a `FirebaseAuthService` implementation in the Data Layer.
- **DTOs:** The DTOs should be mapped to domain entities in the Data Layer. This ensures that the Domain Layer is not affected by changes in the backend's data model.
- **Error Handling:** A generic error handling mechanism should be implemented to handle different types of backend errors.
### Suggested Design Improvements
- **Introduce a Service Locator:** Use a service locator like `get_it` to decouple the layers and make it easier to swap out implementations.
- **Define Abstract Data Sources:** Instead of directly calling the API client in the repository implementations, introduce abstract data source interfaces (e.g., `UserRemoteDataSource`). This adds another layer of abstraction and makes the repositories more testable.
### Migration Strategies
1. **Define Interfaces:** Start by defining abstract interfaces for all backend interactions (repositories, services).
2. **Implement New Data Layer:** Create a new implementation of the Data Layer for the new backend. This will involve writing new repository implementations, API clients, and DTOs.
3. **Swap Implementations:** Use the service locator to swap the old Data Layer implementation with the new one.
4. **Test:** Thoroughly test the application to ensure that everything works as expected with the new backend.
By following these recommendations, the Krow Mobile Staff App can be migrated to a new backend with minimal impact on the overall architecture and business logic.