How prantascode/meal-management-system works
1. System shape
- This is a two-part full-stack application: a Spring Boot backend and a React + TypeScript frontend.
- The backend exposes business APIs for meal/mess operations; the frontend is a Vite-based SPA that consumes those APIs through an Axios client.
2. Core domain
- The business model is centered on a single mess or meal organization and its participants.
- Main persisted entities are Member, Mess, MealEntry, Deposit, Expense, MealRequest, MonthlyReport, RefreshToken, plus OAuth-related state/token records.
3. Backend layering
- The Java backend follows a standard layered structure:
- Controller: HTTP endpoints and request/response handling.
- Service: business rules and orchestration.
- Repository: Spring Data JPA persistence.
- Entity: database models.
- Dto: API input/output contracts.
- Security/Config: authentication and external auth setup.
4. Authentication and authorization boundary
- Security is handled with Spring Security + JWT.
- JwtFilter sits in the request pipeline to validate tokens before protected controllers execute.
- CustomUserDetailsService and MemberUserDetails connect application users to Spring Security.
- Refresh token support is explicit via RefreshToken, RefreshTokenRepository, and RefreshTokenService.
5. User roles and access model
- The readme indicates role separation for Admin, Manager, and Member, and the controller set reflects that multi-role workflow.
- Role-specific access likely determines who can create messes, manage members, record meals, enter deposits/expenses, and view reports.
6. Operational workflow APIs
- Business controllers are organized by function:
- MealController for meal entry management.
- DepositController and ExpenseController for financial inputs.
- MemberController for member lifecycle and profile data.
- MealRequestController for member meal-add requests.
- ReportController for monthly summaries and balances.
- Each controller delegates to a service that persists through the corresponding repository.
7. Financial and reporting flow
- The system aggregates meals, deposits, and expenses into monthly reporting.
- ReportService and MonthlyReport indicate a derived-data layer rather than only raw transactions.
- Meal rate, member-wise balance, and monthly calculations are central outputs consumed by both admin and member views.
8. Member self-service flow
- Members can log in, inspect their meal/deposit/report data, submit meal requests, and update profile/password.
- The frontend has dedicated pages for UpdateProfile, UpdatePassword, and dashboard-style read views, showing this is not purely admin-operated.
9. External integrations
- GmailSenderService is used to send credentials or notifications by email.
- GoogleOAuthConfig, GoogleOAuthController, and GoogleOAuthCallbackController show a separate Google OAuth login/integration path.
- AdminGoogleToken and GoogleOAuthState suggest the app stores OAuth tokens/state server-side for secure callback handling.
- AiController indicates AI-driven insights, and the README identifies Gemini API as the external AI service.
10. Frontend architecture
- The UI is a React SPA with feature pages for Dashboard, Login, Members, Meals, Deposits, Expenses, MealRequests, Reports, CreateMess.
- Layout and Sidebar provide the shared shell/navigation, while AiInsights is a reusable component for the AI feature.
- axiosInstance.ts is the key integration boundary between UI and backend, likely attaching auth headers and centralizing API calls.
11. Data exchange contract
- The backend uses DTOs for request/response shaping rather than exposing entities directly.
- Examples include login/register DTOs, meal/deposit/expense DTOs, profile update DTOs, report DTOs, and meal request response DTOs.
- This implies a clean API boundary between UI and persistence models.
12. Persistence and runtime
- The app uses MySQL via Spring Data JPA / Hibernate on the backend.
- Runtime/configuration is Maven-based (pom.xml, Maven wrapper) with environment values in application.properties.
- The frontend is built with Vite, Tailwind CSS, and TypeScript.
13. End-to-end request path
- Typical flow: browser action → React page/component → Axios call → Spring controller → service logic → repository/database → DTO response → UI update.
- Authenticated calls pass through JWT validation first; sensitive features are gated by role and token checks.
14. Repository maturity note
- The repository is clearly organized as a production-style monolith with a separate SPA frontend.
- Test coverage appears minimal in the tree, with only the default Spring Boot application test present, so the architecture is driven primarily by the runtime layers above.
Main entry points: Controller API controllers · Repository Repositories · Security Auth flow · axiosInstance.ts Axios client
Components 18
Spring Boot backend
Java monolith exposing business APIs, security, persistence, and integrations.
- API controllers · HTTP boundary for auth, members, meals, finances, reports, AI, and Google OAuth callbacks.
MealManagement/src/main/java/com/pranta/MealManagement/Controller - Auth flow · JWT authentication, user-details mapping, refresh tokens, and security configuration.
MealManagement/src/main/java/com/pranta/MealManagement/Security - Security config · Spring Security and OAuth configuration for protected routes and external login.
MealManagement/src/main/java/com/pranta/MealManagement/Config/SecurityConfig.java - User details · Bridges application members to Spring Security principals.
MealManagement/src/main/java/com/pranta/MealManagement/Config/CustomUserDetailsService.java - Member service · Manages registration, profile updates, and member lifecycle.
MealManagement/src/main/java/com/pranta/MealManagement/Service/MemberService.java - Meal service · Handles meal entry operations and meal-related business rules.
MealManagement/src/main/java/com/pranta/MealManagement/Service/MealService.java - Finance services · Deposit and expense workflows that feed financial state and reports.
MealManagement/src/main/java/com/pranta/MealManagement/Service/DepositService.java - Request service · Processes member meal requests and approval state.
MealManagement/src/main/java/com/pranta/MealManagement/Service/MealRequestService.java - Report service · Builds monthly summaries, balances, and derived mess reporting data.
MealManagement/src/main/java/com/pranta/MealManagement/Service/ReportService.java - External integrations · Gmail notifications, Google OAuth, and Gemini-backed AI features.
MealManagement/src/main/java/com/pranta/MealManagement/Service/GmailSenderService.java - Domain entities · Persisted core records for members, messes, meals, deposits, expenses, requests, reports, and tokens.
MealManagement/src/main/java/com/pranta/MealManagement/Entity - Repositories · Persistence boundary for querying and storing domain entities.
MealManagement/src/main/java/com/pranta/MealManagement/Repository - DTO contracts · Request and response shapes for auth, profile, meals, finances, requests, and reports.
MealManagement/src/main/java/com/pranta/MealManagement/Dtos - App runtime · Main Spring Boot application entry point and runtime bootstrap.
MealManagement/src/main/java/com/pranta/MealManagement/MealManagementApplication.java
React frontend
Vite-based SPA that consumes backend APIs through a shared Axios client.
- UI shell · Shared app layout and navigation for the SPA.
meal-management-ui/src/components/Layout.tsx - Feature pages · Dashboard and workflow pages for login, members, meals, finances, requests, reports, profile updates, and mess creation.
meal-management-ui/src/pages - AI insights · Reusable UI for displaying AI-generated summaries or suggestions.
meal-management-ui/src/components/AiInsights.tsx - Axios client · Central HTTP client used by the SPA to call backend endpoints and attach auth context.
meal-management-ui/src/api/axiosInstance.ts
Connections 23
- UI shell → Feature pages: navigates · Shell routes users to feature pages.
- Feature pages → Axios client: calls · Pages fetch and mutate data through the shared client.
- AI insights → Axios client: calls · AI UI requests backend insights through the API client.
- Axios client → API controllers: HTTP · SPA requests reach backend controllers.
- API controllers → Auth flow: protects · Controllers rely on JWT validation and security configuration.
- Auth flow → Security config: configured by · Security filter chain and OAuth wiring are defined here.
- Auth flow → User details: loads users · Spring Security resolves member principals through custom user details.
- API controllers → DTO contracts: maps to · Incoming and outgoing payloads are shaped with DTOs.
- API controllers → Member service: delegates · Member endpoints call the member service.
- API controllers → Meal service: delegates · Meal endpoints call the meal service.
- API controllers → Finance services: delegates · Deposit and expense endpoints call finance services.
- API controllers → Request service: delegates · Meal request endpoints call the request service.
- API controllers → Report service: delegates · Report endpoints call reporting logic.
- API controllers → External integrations: delegates · Auth, email, OAuth, and AI endpoints bridge to integrations.
- Member service → Repositories: persists via · Member changes are stored through repositories.
- Meal service → Repositories: persists via · Meal entries are stored through repositories.
- Finance services → Repositories: persists via · Deposits and expenses are stored through repositories.
- Request service → Repositories: persists via · Meal requests are stored through repositories.
- Report service → Repositories: reads via · Monthly reporting aggregates persisted transactions and reports.
- Repositories → Domain entities: stores · Repositories manage the JPA entities.
- External integrations → Domain entities: uses state · OAuth tokens and state records are persisted as entities.
- App runtime → API controllers: boots · Application startup activates controllers and supporting beans.
- App runtime → Auth flow: loads · Security components are wired at application startup.