bipproduction/hipmi

1. System shape

- This is a Next.js + TypeScript monorepo-style application centered on a single web app, but organized as multiple product domains inside one codebase.

- The product is a multi-role platform with user, admin, and super-admin experiences, covering auth, home, katalog/profile, donasi, event, forum, investasi, job, map, voting, collaboration, notifications, and logs.

2. Presentation layer

- The primary UI lives under src/app using the Next.js App Router.

- Route groups such as (auth), (admin), (not-user), and dev/(user|admin) separate user journeys and privileged layouts.

- Most screens are thin route entrypoints that render feature views from src/app_modules, which acts as the real presentation/component layer.

3. Feature-module boundary

- The codebase is split by domain under src/app_modules/<domain>.

- Each domain usually contains:

- UI components

- view/layout wrappers

- feature-specific “fun” functions for CRUD and status transitions

- local API client wrappers

- state modules

- domain interfaces/types

- This is the main architectural boundary: routes call feature views; views call domain functions; domain functions call API routes or server utilities.

4. Backend API layer

- Business operations are exposed through a large set of Next.js route handlers in src/app/api//route.ts**.

- The API surface is domain-aligned and includes both public and admin endpoints, for example:

- auth: login, register, logout, validation, OTP

- donasi/event/forum/investasi/job/vote CRUD and status flows

- admin dashboards and moderation endpoints

- uploads, image serving, PDF/image conversion, logs, cookies, version

- This API layer is the bridge between browser UI and persistence.

5. Data model and persistence

- The system uses PostgreSQL with Prisma as the ORM.

- Database structure is defined in prisma/schema.prisma, with many migrations showing the schema has evolved over time.

- prisma/seed.ts plus JSON seed data in src/bin/seeder initialize master data like status lists, categories, banks, emotions, business fields, and app metadata.

- A backup.sql file suggests database snapshots/backups are part of operational practice.

6. Auth, session, and access control

- Authentication flows are implemented in src/app/(auth) and src/app_modules/auth.

- There are dedicated routes for login, registration, OTP validation/resend, logout, and “invalid/waiting/validasi” states.

- Session handling and token/cookie logic live in shared libs and auth helpers.

- src/middleware.ts and the router helpers in **src/lib/router_*** are important for guarding routes and steering users into the correct role-specific experience.

7. Role-based application surfaces

- The app has clearly separated experiences for:

- regular users: home, dashboards, creation/edit/detail flows

- admins: moderation dashboards, status management, master data, user access, logs

- super admin / developer: app information, user access, main dashboard, system-level admin screens

- The dev route tree mirrors many production domains and suggests a QA/staging-like UI path for testing user/admin flows.

8. Domain workflows and shared patterns

- Most business domains follow the same lifecycle pattern:

- draft → review → publish → reject → archive/riwayat

- This pattern appears across donasi, event, forum, investasi, job, vote, and is reinforced by dedicated status endpoints and admin moderation screens.

- Each domain also has “detail”, “main”, “create”, “edit”, and “status” views, which makes the architecture highly repeatable.

9. Media and file handling

- The platform stores and serves many kinds of assets: avatars, banners, posters, PDFs, dokumen, prospektus, bukti transfer, images.

- File operations are handled through API routes like /api/image/upload, /api/image/delete, and domain-specific image/file endpoints.

- There are helpers for upload validation, storage upload, and PDF-to-image conversion, indicating media processing is a first-class subsystem.

10. Notifications and user alerts

- Notifications are a shared cross-cutting subsystem under src/app/api/notifikasi, src/app/api/notifications, and src/app_modules/notifikasi.

- Notifications are categorized by domain: collaboration, donasi, event, forum, investasi, job, voting.

- Admin notification helpers also perform status checks on domain objects, which means notification generation is tied to workflow transitions.

11. External services and operational dependencies

- Midtrans integration is present for payment/transaction flows, especially in investasi and likely donasi-related payment/invoice handling.

- There are utilities for realtime/messaging and a collaboration/chat subsystem, suggesting some live interaction beyond simple request/response.

- Deployment notes in the README mention Debian 11, PM2, and a production setup around Next.js + Postgres.

12. Global/shared infrastructure

- Shared libraries in src/lib centralize environment config, token handling, route maps, constants, Prisma client access, and global state.

- Shared utilities in src/util handle backend/frontend logging and messaging clients.

- Global UI and component libraries in src/app_modules/_global provide reusable layout templates, loading states, notifications, button/input primitives, and common formatting helpers.

13. Logs, diagnostics, and admin observability

- There is a dedicated logs area in the app and filesystem, including frontend/backend log directories.

- API routes for logs and log viewing indicate the admin side can inspect runtime activity directly from the app.

14. What the architecture diagram should emphasize

- Put Next.js App Router at the center, split into route groups for auth/user/admin/dev.

- Show src/app_modules as the domain UI/application logic layer beneath routes.

- Show src/app/api as the backend boundary for all CRUD, status workflows, uploads, and admin operations.

- Show Prisma/Postgres as the persistence layer.

- Add Midtrans, file/image storage, notifications, and realtime/chat as supporting integrations that cut across multiple domains.