How wani21/minicorebankingsystem works
1. This repository is a split full-stack banking application: a Spring Boot backend in backend/coreBanking and a React/Vite frontend in frontend/MiniCoreBankSystem. The architectural boundary is cleanly separated into API/backend logic and browser UI.
2. The backend is organized in a classic layered Spring structure:
- controller exposes HTTP endpoints
- Service contains business logic
- Repository provides database access via Spring Data JPA
- Entity maps persistent tables
- DTO carries request/response payloads
- Util contains shared helpers such as JWT handling
3. The main backend domain appears to be user onboarding and identity management rather than transactional core banking. The concrete backend entities are SignUpUserEntity and UserKYCEntity, which support registration, authentication, and KYC workflows. The SQL scripts in backend/SQLFile reflect those data stores, including login users and KYC request tables.
4. Authentication is JWT-based. JwtUtil is the central token utility, and LoginAuthController plus UserAuthService form the login/auth boundary. This implies the frontend likely authenticates once, then sends tokens on protected requests, with route protection handled client-side.
5. Registration and credential management are handled separately from login. UserSignUpController and UserSignUpService manage sign-up flows, while UserCredentialsCheckRepo and GetStatusRepo support validation and account/status lookups. That separation suggests the backend enforces different persistence/query paths for account creation versus login verification.
6. Password recovery is its own subsystem. The ForgetPasswordControllers package contains controllers for retrieving a security question, checking the answer, and changing the password. The DTOs SecurityAnswerDTO and ChangePasswordDTO, plus ChangePasswordService, indicate a multi-step recovery flow rather than a single reset endpoint.
7. KYC is modeled as a dedicated workflow. KYCProcessController, KYCProcessRepo, and KYCProcessDTO form the KYC submission path, likely writing user identity/compliance data into UserKYCEntity. This is a distinct business boundary from login and signup, which is important for diagramming.
8. The backend also exposes a user/admin data retrieval path. GetAllUserService and AllUsersDataDTO, along with the ShowUsersData page on the frontend, suggest an administrative read model for listing users or reviewing onboarding status. The presence of AdminPage in the frontend reinforces that this is an operator-facing capability.
9. HealthCheckController/TestController is a lightweight operational endpoint, separate from the business domains. It is likely used for deployment validation or connectivity checks and can be represented as an independent support path in the architecture.
10. The frontend is a React SPA with page-level routing. App.jsx, main.jsx, and ProtectedRoute.jsx define the shell and route guard behavior, while the pages directory contains feature screens such as LoginPage, SignUp, Dashboard, Profile, Accounts, Transactions, KYCFormPage, and password recovery pages.
11. Frontend pages map closely to backend capabilities: signup/login, KYC submission, password recovery, user status display, and admin/user listings. This suggests the UI is mostly a consumer of the backend APIs, not a separate business engine. ProtectedRoute.jsx is the main client-side security boundary.
12. AppConfig.java and WebConfiguration.java are the backend’s cross-cutting configuration layer. They likely define app-wide beans and web/CORS or MVC behavior, which matters because the React frontend must communicate with the Spring Boot API across the browser boundary.
13. The runtime stack is Spring Boot + Spring Security + Spring Data JPA + MySQL on the backend, and React + Vite on the frontend. The database is explicitly MySQL, and the SQL scripts suggest the schema is at least partially managed outside of JPA auto-generation.
14. For an architecture diagram, the key flows are: browser UI → protected React routes → REST controllers → service layer → JPA repositories → MySQL; and login/signup/KYC/password recovery are the main business subflows. The most important boundaries are client vs server, controller vs service, and authentication/identity vs KYC/compliance.
Main entry points: App.jsx App shell · LoginControllers Auth API · UserAuthService Auth services · SignUpUserEntity.java Signup data
Components 19
Frontend SPA
React/Vite browser application and route-level screens.
- App shell · Main SPA entry, route wiring, and protected navigation.
frontend/MiniCoreBankSystem/src/App.jsx - Protected route · Client-side access control for authenticated pages.
frontend/MiniCoreBankSystem/src/Components/ProtectedRoute.jsx - Login · User sign-in screen.
frontend/MiniCoreBankSystem/src/pages/LoginPage/LoginPage.jsx - Sign up · Account registration screen.
frontend/MiniCoreBankSystem/src/pages/SignUp/SignUp.jsx - KYC form · Identity and compliance submission screen.
frontend/MiniCoreBankSystem/src/pages/KYCFormPage/KYCFormPage.jsx - Recovery UI · Password recovery and answer verification screens.
frontend/MiniCoreBankSystem/src/pages/ForgetPasswordModule - Admin views · Operator-facing pages for user and status review.
frontend/MiniCoreBankSystem/src/pages/AdminPage/AdminPage.jsx - User pages · Authenticated user screens such as dashboard, profile, accounts, and transactions.
frontend/MiniCoreBankSystem/src/pages/Dashboard/Dashboard.jsx
Backend API
Spring Boot REST backend with layered business logic.
- Auth API · Login and signup endpoints plus status lookup.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/controller/LoginControllers - Recovery API · Multi-step password recovery endpoints.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/controller/ForgetPasswordControllers - KYC API · KYC submission endpoint.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/controller/KYCProcessController/KYCProcessController.java - Auth services · Authentication, signup, and user listing business logic.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/Service/UserAuthService - Recovery service · Password reset orchestration and validation.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/Service/ChangePasswordService.java - JWT util · Shared token creation and validation utility.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/Util/JwtUtil.java
Persistence
Database entities, repositories, and SQL-backed schema.
- Signup data · User registration persistence and credential/status queries.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/Entity/SignUp/SignUpUserEntity.java - KYC data · KYC request storage and access path.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/Entity/UserKYC/UserKYCEntity.java - MySQL · Relational backing store defined by SQL scripts and JPA mappings.
backend/SQLFile/logindb_login_users.sql
Support
Cross-cutting configuration and operational endpoints.
- Config · Application and web configuration layer.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/Configuration/AppConfig.java - Health check · Lightweight operational endpoint for deployment and connectivity checks.
backend/coreBanking/src/main/java/com/bankingSystem/coreBanking/controller/HealthCheckController/TestController.java
Connections 23
- App shell → Protected route: protects · SPA routes use a client-side auth guard.
- App shell → Login: routes to · Entry flow for authentication.
- App shell → Sign up: routes to · Entry flow for registration.
- App shell → KYC form: routes to · Entry flow for KYC submission.
- App shell → Recovery UI: routes to · Password recovery screens.
- App shell → Admin views: routes to · Operator-facing pages.
- App shell → User pages: routes to · Authenticated user pages.
- Protected route → Auth API: calls · Protected views depend on login state and token-backed API access.
- Login → Auth API: authenticates · Submits login credentials.
- Sign up → Auth API: registers · Submits new user details.
- KYC form → KYC API: submits · Sends identity/compliance data.
- Recovery UI → Recovery API: recovers · Drives security-question and password-change flow.
- Admin views → Auth API: reads · Loads user lists and onboarding/status data.
- Auth API → Auth services: delegates · Controllers hand off to business services.
- Recovery API → Recovery service: delegates · Recovery endpoints use dedicated service logic.
- KYC API → KYC data: writes · KYC submissions are persisted through the KYC model.
- Auth services → Signup data: uses · Signup and credential/status logic reads and writes user records.
- Auth services → JWT util: issues tokens · Authentication uses JWT creation/validation.
- Recovery service → Signup data: verifies · Recovery flow checks user identity and updates credentials.
- Signup data → MySQL: persists to · User registration tables are backed by MySQL.
- KYC data → MySQL: persists to · KYC request tables are backed by MySQL.
- Config → Auth API: configures · Web and application configuration support the REST layer.
- Health check → MySQL: checks · Operational endpoint can validate backend connectivity.