purvapatil11/kruhsi-mitr

1. Overall shape

- This is a Next.js App Router application that combines two product flows in one repo: a Farmer mandi price tracker and an MSME credit scorer.

- The architecture is split between UI routes under app/, server API routes under app/api/, and a small shared backend layer under lib/ and models/.

2. Primary user-facing boundaries

- app/page.js is the landing page that routes users into the two main experiences.

- app/farmer/page.js is the mandi-prices experience.

- app/msme/page.js is the credit-scorer experience.

- app/about/page.js and app/auth/page.js are additional supporting pages, likely informational and auth-related, but they are not the core product boundary.

3. Farmer mandi price flow

- The farmer UI depends on app/api/prices/route.js to fetch mandi data.

- That API route delegates to lib/agmarknet.js, which acts as the integration layer for Agmarknet / data.gov.in mandi price data.

- The API returns current prices and related trend data to the frontend, which can then display the “best mandi” ranking and historical trend visualization described in the README.

4. Price data integration

- lib/agmarknet.js is the external-data adapter for mandi information.

- This is the key boundary between the app and the public data source, and it isolates the rest of the system from API-specific details, parsing, and normalization.

- From an architecture perspective, this is the main read-only data ingestion path in the repo.

5. Alerting flow

- app/api/alerts/route.js is the alert lifecycle endpoint.

- The README indicates it supports creating alerts and checking them later, which implies a server-side stored alert record plus a background check mechanism.

- When alert conditions are met, the route uses lib/whatsapp.js to send a WhatsApp notification.

6. Persistence layer

- lib/mongodb.js is the database connection helper, so MongoDB is the persistence backend for alert data and any related records.

- models/index.js contains the Mongoose schemas/models, likely for alerts and business/MSME-related entities.

- This gives the architecture a clear separation: routes orchestrate, lib/ connects to services, and models/ defines stored domain data.

7. MSME credit-scoring flow

- app/msme/page.js is the UI for the MSME product.

- app/api/score/route.js is the computation endpoint for the credit scorer.

- That route delegates to lib/scorer.js, which implements the rule-based 5-signal scoring engine described in the README.

8. Scoring and scheme eligibility

- lib/scorer.js is a pure business-logic module, separate from persistence and external integrations.

- The output is used to show a score, tips for improvement, and likely scheme eligibility guidance for programs such as PM Mudra, CGTMSE, PSB Loans, and Stand-Up India.

- This subsystem is computation-heavy but does not appear to depend on external APIs; it is local business logic.

9. WhatsApp messaging boundary

- lib/whatsapp.js encapsulates outbound messaging, likely via Twilio WhatsApp as noted in the README.

- This keeps notification transport outside of the alerting route logic and makes messaging a separate infrastructure concern.

- The alert system therefore has a clear chain: store alert in MongoDB, evaluate later, then send via WhatsApp.

10. Scheduled/background execution

- The README references a Vercel cron job that checks alerts daily at 7am IST.

- That means the alert system has both interactive API entry points and a scheduled server-side execution path.

- This is important architecturally because alert delivery is not purely user-triggered; it is also time-driven.

11. Request/response orchestration

- The app/api/*/route.js files are the main orchestration layer.

- They accept frontend requests, call the shared service modules in lib/, and return data to the UI.

- The app is therefore organized as a thin API layer over reusable domain modules rather than embedding business logic directly in pages.

12. Front-end composition

- The app/layout.js and app/globals.css files define the shared application shell and styling.

- tailwind.config.js and postcss.config.js indicate the UI is styled with Tailwind CSS.

- The frontend is a standard Next.js server/client page structure, but the repo’s distinctive architecture is the split between the two product areas and the reusable backend services.

13. Key external systems

- Agmarknet/data.gov.in: source of mandi prices.

- MongoDB: persistence for alerts and related records.

- Twilio WhatsApp: outbound alert delivery.

- Vercel Cron: scheduled alert checks.

- These external services are central to the product, so any architecture diagram should show them as first-class dependencies rather than incidental tooling.

14. Most important architectural boundaries to diagram

- Separate the app into:

- User-facing pages

- API routes

- Shared domain logic in lib/

- Persistence models in models/

- External services

- The two product lines share infrastructure but not core business logic: mandi prices/alerts on one side, MSME scoring on the other.

15. High-level data flow summary

- Farmer flow: user page → prices API → Agmarknet adapter → external mandi data → UI.

- Alert flow: user page → alerts API → MongoDB → scheduled check → WhatsApp notification.

- MSME flow: user page → score API → scoring engine → score/scheme guidance in UI.