How abhishek2586/fasalniti works
1. System shape
FasalNiti is a three-tier agriculture decision system: a React/Vite client in src/, a Node/Express API in server/, and a Python ML service in ml-service/. The main architectural boundary is: user interaction in the frontend, orchestration and business rules in the backend, and heavy forecasting/calibration in the Python service.
2. Frontend responsibilities
The frontend is organized around user-facing decision pages, not generic CRUD screens. Key pages include PlantingAdvisorPage, HarvestPlannerPage, CropRecPage, DiseaseDetectPage, WeatherIrrigationProfitMarket.jsx, and ChatbotPage. Shared UI lives under components/, with app-wide state in context/, local behavior hooks in hooks/, and translated strings/design tokens in constants/.
3. Frontend-to-backend communication
src/api/agriBackend.js is the main client for the Node API, while src/api/claude.js and src/api/config.js indicate additional AI/API wiring. The frontend does not appear to talk directly to MongoDB or the ML service; it calls the backend, which then fans out to external services and the ML microservice.
4. Backend entry and request boundary
server/server.js and server/app.js are the runtime entry points for the Express app. Routing is split by domain under server/routes/, with matching controllers in server/controllers/. This is the main API surface for planting, harvest, disease, weather, market, chatbot, satellite, fertilizer, irrigation, crop, profit, auth, and location features.
5. Business-logic layer
The real decision-making is in server/services/. The notable core services are gadi.service.js, cropEconomics.service.js, priceIntelligence.service.js, planting.service.js, harvest.service.js, and harvestWindow.service.js. These services likely implement the framework’s decision indices and economic logic, while controllers mainly validate requests and format responses.
6. Persistence and domain models
server/models/ contains MongoDB-backed entities such as user.js, Market.js, HistoricalPrice.js, PriceForecast.js, PlantingRecommendation.js, and DisposalRecommendation.js. There is also CropEconomicsConstants.js and labels.txt/model.h5, which suggests the backend includes packaged model assets for classification or inference, likely around disease detection.
7. Cross-cutting middleware and API safety
Authentication and location scoping are handled by middleware in server/middleware/, especially auth.middleware.js and location.middleware.js. error.middleware.js centralizes failure handling, and utils/responseHandler.js suggests the API uses a consistent response envelope. This boundary matters because many endpoints depend on authenticated user context or farm location.
8. External integrations
The backend is the integration hub for OpenWeather, Groq, and other AI fallbacks. The README also references Hugging Face and Gemini as backup providers, and the tree includes bhashini.service.js, which aligns with multilingual speech/translation support. server/services/location.service.js and server/services/weather.service.js indicate the app also normalizes geospatial and weather inputs before feeding them into recommendations.
9. Planting and harvest decision flows
The two primary product flows are distinct:
- Planting: inputs from soil/location/crop context flow through planting and crop-suitability logic to produce a planting recommendation.
- Harvest: current market prices, decay economics, weather, and disease severity feed harvest planning logic to produce sell/store/dehydrate recommendations.
The harvest side is more data-intensive because it combines price forecasting, perishability, and processing costs.
10. ML microservice boundary
ml-service/ is a separate Python service with its own Dockerfile, dependencies, and training script. It is used for computationally expensive forecasting and calibration, including Prophet-based price forecasting and synthetic benchmarking. The backend calls it via ML_SERVICE_URL, so the Node layer remains the orchestration point while Python owns the model runtime.
11. Offline data and benchmarking
The data/synthetic/ directory stores benchmark outputs such as results.csv, scenarios.csv, and summary.json. ml-service/training/synthetic_benchmark.py generates these artifacts, which are used to validate the economic value of the decision engine. This is an offline analytics path, separate from the live user-request path.
12. Deployment and packaging
The presence of capacitor.config.json suggests the frontend can be packaged as a hybrid mobile app, even though the core app is a web frontend. vercel.json implies frontend deployment support, while server/package.json and ml-service/requirements.txt keep backend and ML runtimes isolated. The architecture therefore supports local development as well as split deployment of UI, API, and ML components.
Main entry points: planting.service.js Decision services · App.jsx App shell · app.js Express app · agriBackend.js API client
Components 21
Frontend
React/Vite user interface and client-side orchestration.
- App shell · Top-level frontend application composition and routing.
src/App.jsx - Decision pages · Main user-facing planning, detection, and advisory screens.
src/pages/index.jsx - Chatbot UI · Frontend conversational assistant entry point.
src/pages/ChatbotPage.jsx - App state · Global client state for auth and app-wide data.
src/context/AppContext.jsx - API client · Frontend gateway to the Node backend and AI providers.
src/api/agriBackend.js
Backend API
Express API, business logic, persistence, and integrations.
- Server entry · Runtime entry for the Node/Express API.
server/server.js - Express app · API wiring, middleware, and route registration.
server/app.js - API routes · Domain route surface for agriculture features.
server/routes/planting.routes.js - Controllers · Request validation and response shaping for each domain.
server/controllers/planting.controller.js - Decision services · Core recommendation, forecasting, and orchestration services.
server/services/planting.service.js - Weather service · Weather normalization and weather-driven inputs.
server/services/weather.service.js - Market service · Market price intake and price intelligence logic.
server/services/market.service.js - Location service · Farm/location scoping and geospatial normalization.
server/services/location.service.js - Crop suitability · Crop and planting suitability rules for advisory flows.
server/services/cropSuitability.service.js - Harvest logic · Harvest timing and sell/store/dehydrate recommendation logic.
server/services/harvest.service.js - Economics · Crop economics, perishability, and value modeling.
server/services/cropEconomics.service.js - Mongo models · Mongo-backed domain records and price forecast storage.
server/models/PriceForecast.js - Middleware · Authentication, location scoping, and error handling.
server/middleware/auth.middleware.js
ML Service
Python forecasting and benchmarking service.
- ML API · Separate Python runtime for forecasting and calibration.
ml-service/app.py - Benchmarking · Offline synthetic benchmark generation and evaluation.
ml-service/training/synthetic_benchmark.py
Offline Data
Synthetic benchmark outputs used for evaluation.
- Synthetic data · Offline benchmark results and scenario outputs.
data/synthetic/summary.json
Connections 21
- App shell → Decision pages: renders · Top-level app composes the decision pages.
- App shell → Chatbot UI: routes to · App exposes the assistant experience.
- App shell → App state: uses · Shared client state supports auth and session flow.
- Decision pages → API client: calls · Decision screens request backend data and recommendations.
- Chatbot UI → API client: calls · Chat UI uses the API client for assistant requests.
- API client → Server entry: sends requests to · Frontend talks to the Node API boundary.
- Server entry → Express app: boots · Server entry initializes the Express application.
- Express app → Middleware: applies · Middleware handles auth, location, and errors.
- Express app → API routes: mounts · Express app registers domain routes.
- API routes → Controllers: delegates to · Routes hand off request handling to controllers.
- Controllers → Decision services: orchestrates · Controllers invoke business logic services.
- Decision services → Weather service: uses · Decision flows depend on weather inputs.
- Decision services → Market service: uses · Harvest and profit logic depend on market data.
- Decision services → Location service: uses · Recommendations are scoped by location.
- Decision services → Crop suitability: uses · Planting decisions rely on crop suitability rules.
- Decision services → Harvest logic: uses · Harvest recommendation flow is centralized here.
- Decision services → Economics: uses · Economic scoring feeds planning and harvest choices.
- Decision services → Mongo models: persists to · Services store and retrieve domain records.
- Decision services → ML API: calls · Backend offloads forecasting and calibration to Python.
- ML API → Benchmarking: supports · Python service includes offline evaluation tooling.
- Benchmarking → Synthetic data: produces · Benchmark runs generate synthetic result artifacts.