hilalinabil/telecom_application

1. This repository is a full-stack telecom network management system split into two clear deployable parts: a Spring Boot backend at the repository root and a React frontend under frontend/. The backend exposes JSON APIs; the frontend is a single-page app that consumes them.

2. The backend follows a classic layered architecture: controllers handle HTTP requests, services contain business logic, repositories access MongoDB, and models define persisted domain objects. DTOs sit between API payloads and internal models, which keeps the transport layer separate from the persistence model.

3. The core domain is telecom infrastructure management. The main entity families are Datacenter, Repartiteur/OLT, Splitter, ClientBox, Client, FibrePath, Equipement, and GeoPoint. These map directly to the network hierarchy described in the README: datacenter → distribution node → splitter → client box → customer.

4. Persistence is MongoDB-based, not relational. The repository layer is made of Spring Data-style repositories for each aggregate. Domain enums such as Role, UserStatus, NetworkStatus, FibreStatus, and others encode controlled lifecycle and classification values across the system.

5. Authentication and authorization are a dedicated subsystem. Backend security is implemented with Spring Security, JWT, a custom user-details service, a JWT filter, and a security config. Users authenticate with a matricule/password pair, and role-based access is enforced for SUPER_ADMIN, ADMIN, and TECHNICIAN.

6. User administration is tightly controlled. There is no public registration flow; user creation is performed by authorized admins according to the role hierarchy. The backend includes dedicated auth and user controllers/services, plus password-change and user-creation DTOs.

7. The frontend is organized around routes and feature pages rather than a single generic screen. pages/ contains views like dashboards, asset management screens, login, profile, logs, and map pages. components/ holds reusable UI pieces such as layout, header, sidebar, protected route guard, data table, and network map.

8. Shared frontend state is centralized in React contexts. AuthContext manages login/session state, while ThemeContext handles UI theming. Route protection is enforced on the client with ProtectedRoute, matching the backend’s JWT/role model.

9. The frontend data-access pattern is hook-based. Custom hooks such as useCrud, useDashboard, and useNetworkMap encapsulate API calls, filtering, and view-specific data loading. All HTTP traffic goes through services/api.js, which is the frontend’s main boundary to the backend API.

10. Geographic and topology visualization is a distinct subsystem. NetworkMap and MapPage use Leaflet/OpenStreetMap to render nodes and fiber routes. The backend’s GeoPoint and FibrePath resources supply the location and path data used for map rendering.

11. Dashboarding is another cross-cutting feature. The backend has a DashboardController and DashboardService that aggregate infrastructure and capacity metrics, and the frontend dashboard pages consume those summaries to show totals, occupancy, and network status indicators.

12. Auditability is built into the data model and operations. There is an ActivityLog model/repository/service/controller for tracing actions, and the README indicates record metadata such as CreatedBy, CreatedAt, and UpdatedAt. This makes operational history part of the architecture, not an afterthought.

13. Error handling and input validation are centralized on the backend. Request DTOs define the accepted API contract, while GlobalExceptionHandler and ApiException provide consistent error responses. This helps keep controllers thin and predictable.

14. Deployment/runtime tooling also shapes the architecture: the backend is built with Maven and Spring Boot 3, while the frontend uses Vite and is packaged with a Dockerfile plus Nginx for static serving. The repo includes Maven wrapper files and a Spring Boot test class, indicating standard Java service build/test workflows.

15. For an architecture diagram, the important boundaries are: browser UI → React app → authenticated API calls → Spring controllers → services → MongoDB, with a separate map/visualization path and a shared security boundary wrapping all protected resources.