refactor: restructure monorepo to align with industry standards
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
@@ -24,6 +24,40 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Prototypes",
|
||||
"iconColorClass": "bg-indigo-100",
|
||||
"iconPath": "assets/images/icon-design.svg",
|
||||
"links": [
|
||||
{
|
||||
"title": "Mobile Client MVP",
|
||||
"url": "/prototypes/mobile/client/index.html",
|
||||
"badge": "Concept",
|
||||
"badgeColorClass": "bg-blue-500",
|
||||
"containerClass": "bg-gradient-to-r from-blue-50 to-indigo-100 hover:from-blue-100 hover:to-indigo-200",
|
||||
"iconClass": "w-2 h-2 bg-blue-500 rounded-full",
|
||||
"textHoverClass": "group-hover:text-blue-700"
|
||||
},
|
||||
{
|
||||
"title": "Mobile Staff MVP",
|
||||
"url": "/prototypes/mobile/staff/index.html",
|
||||
"badge": "Concept",
|
||||
"badgeColorClass": "bg-green-500",
|
||||
"containerClass": "bg-gradient-to-r from-green-50 to-emerald-100 hover:from-green-100 hover:to-emerald-200",
|
||||
"iconClass": "w-2 h-2 bg-green-500 rounded-full",
|
||||
"textHoverClass": "group-hover:text-green-700"
|
||||
},
|
||||
{
|
||||
"title": "Web Dashboard MVP",
|
||||
"url": "/prototypes/web/index.html",
|
||||
"badge": "Concept",
|
||||
"badgeColorClass": "bg-purple-500",
|
||||
"containerClass": "bg-gradient-to-r from-purple-50 to-fuchsia-100 hover:from-purple-100 hover:to-fuchsia-200",
|
||||
"iconClass": "w-2 h-2 bg-purple-500 rounded-full",
|
||||
"textHoverClass": "group-hover:text-purple-700"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Legacy Mobile Apps",
|
||||
"iconColorClass": "bg-green-100",
|
||||
@@ -93,7 +127,7 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Design",
|
||||
"title": "Legacy Design",
|
||||
"iconColorClass": "bg-pink-100",
|
||||
"iconPath": "assets/images/icon-design.svg",
|
||||
"links": [
|
||||
@@ -142,4 +176,4 @@
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
]
|
||||
@@ -218,35 +218,3 @@ flowchart TD
|
||||
B5 --> E5[Display profile information];
|
||||
end
|
||||
```
|
||||
|
||||
## 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 backend solution.
|
||||
|
||||
### Tightly Coupled Components
|
||||
|
||||
* **`ApiClient`:** This class is tightly coupled to `graphql_flutter`.
|
||||
* **Firebase Auth:** The authentication logic is directly tied to the `firebase_auth` package.
|
||||
* **BLoCs:** Some BLoCs might have direct dependencies on Firebase or GraphQL-specific models.
|
||||
|
||||
### Abstraction Recommendations
|
||||
|
||||
To make the architecture more backend-agnostic, the following abstractions should be implemented:
|
||||
|
||||
* **Repositories:** Create an abstract `Repository` class for each feature in the `domain` layer. The implementation of this repository will be in the `data` layer. The BLoCs should only depend on the abstract repository.
|
||||
* **Authentication Service:** Create an abstract `AuthService` class that defines the methods for authentication (e.g., `signIn`, `signOut`, `getToken`). The implementation of this service will be in the `data` layer and will use the specific authentication provider (e.g., Firebase Auth, OAuth).
|
||||
* **Data Transfer Objects (DTOs):** Use DTOs to transfer data between the data layer and the domain layer. This will prevent the domain layer from having dependencies on backend-specific models.
|
||||
|
||||
### Suggested Design Improvements
|
||||
|
||||
* **Formalize Clean Architecture:** While the current architecture has elements of Clean Architecture, it could be more formally implemented by creating a clear separation between the `domain`, `data`, and `presentation` layers for all features.
|
||||
* **Introduce Use Cases:** Introduce `UseCase` classes in the `domain` layer to encapsulate specific business operations. This will make the BLoCs simpler and more focused on state management.
|
||||
|
||||
### Migration Strategies
|
||||
|
||||
To replace the current backend with a new one (e.g., REST API, Supabase), follow these steps:
|
||||
|
||||
1. **Implement New Repositories:** Create new implementations of the repository interfaces for the new backend.
|
||||
2. **Implement New Auth Service:** Create a new implementation of the `AuthService` interface for the new authentication provider.
|
||||
3. **Update Dependency Injection:** Use dependency injection (e.g., `get_it` and `injectable`) to provide the new repository and auth service implementations to the BLoCs.
|
||||
4. **Gradual Migration:** If possible, migrate one feature at a time to the new backend. This will reduce the risk of breaking the entire application at once.
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user