shlokapol2005/soilsense

1. High-level shape

SoilSense is a 3-tier application: a React/Vite frontend, a Node/Express backend, and a MongoDB database. In addition, there is a Python-based ML training pipeline that produces serialized models consumed by the app.

2. Frontend boundary

The frontend/ folder is the presentation layer. It uses React with Vite and is organized as a page-based UI with screens for welcome, login/signup, dashboard, soil analysis, weather, calculator, recommendations, and history. App.jsx and main.jsx are the entry points that wire the page flow and global styling.

3. Frontend responsibilities

The UI appears to handle user interaction, form capture, displaying weather/soil outputs, and presenting recommendation results and history. CSS is split per page, suggesting each route/screen is mostly self-contained rather than sharing a large component library.

4. Backend boundary

The backend/ folder is the API and data-access layer. The repo tree shows a Node.js service (server.js) with Express-style route modules under routes/, plus database models under models/. This is the main runtime boundary that the frontend talks to over HTTP.

5. Backend API domains

There are two explicit route domains: authRoutes.js for user authentication and weatherRoutes.js for weather-related operations. That suggests the backend is responsible for both account management and serving weather or prediction-adjacent data to the frontend.

6. Persistence layer

MongoDB is the durable store. The backend includes Mongoose-style models for User and weather, and the README describes a prediction_history collection as well. The data store likely keeps user records, fetched weather snapshots, and historical prediction/recommendation records for later display.

7. Machine learning subsystem

The ML assets live under backend/models_ml/, including serialized models for crop recommendation and nutrient-related predictions (model_N.pkl, model_P.pkl, model_K.pkl, crop_model.pkl) plus label encoders for district and soil type. This indicates inference is model-file-based rather than an online training service.

8. Training pipeline

backend/train_models.py and the CSV datasets show an offline training workflow. The training script likely reads the combined soil/fertilizer dataset, fits the random-forest-based models described in the README, and writes the .pkl artifacts used later by the backend.

9. External weather dependency

The system integrates OpenWeatherMap for real-time weather input. That external API is part of the data flow feeding recommendations, especially because temperature is listed as an input and the backend has a dedicated weather route.

10. Primary data flow

A typical request path is: user enters soil/district information in the React UI → frontend calls the backend API → backend fetches/uses weather data if needed → backend loads the ML model artifacts to generate crop/fertilizer recommendations → result is returned to the UI and optionally stored in MongoDB history.

11. Historical and user-centric flows

The presence of history pages and database collections implies a second flow: recommendation results are persisted and later queried for a user’s past analyses. Authentication likely gates access to personalized history and saved data.

12. Important architectural note

The README describes a Flask backend, but the repository tree shows a Node/Express backend as the active server implementation. For an architecture diagram, the safer interpretation is: React frontend → Node/Express API → MongoDB + local ML artifacts, with Python used for model training/offline generation rather than as the main serving runtime.