How dhanraj84/infracharge works
1. Overall shape
- InfraCharge is a Next.js 14 App Router application with a mixed architecture: mostly server-side API routes in the same repo, a client-heavy map/UI frontend, plus a separate Python ML service for solar-related prediction work.
2. Primary user-facing surfaces
- The main app routes are organized by workflow: home/landing, charging search, route planning, vehicle selection, CO₂ savings, infrastructure planning (“where to build”), assist/chat, contact, auth pages, and an about page.
- This suggests the product is not a single feature app; it is a multi-workflow EV mobility platform with several entry points into the same data layer.
3. Frontend composition
- Reusable UI is concentrated under app/(components), including navigation, hero/marketing sections, route inputs, map widgets, chatbot, location button, theme toggle, and cards/buttons.
- The map-centric components (MapClient, AssistMap) indicate that interactive geospatial rendering is a core presentation layer, especially for charger discovery and route planning.
4. Client state and auth boundary
- context/AuthContext.tsx and app/providers.tsx imply a shared client-side provider model for authentication and global app state.
- The presence of both lib/firebase.ts and lib/firebase-admin.ts shows a split between client Firebase SDK usage in the browser and server-side admin verification/privileged operations in API routes.
5. API layer as the main backend
- The app/api directory acts as the application backend, exposing route handlers for chargers, amenities, geocoding, reverse geocoding, traffic, solar potential, CO₂, vehicles, EV purchases, user profile, chat, and authentication.
- These endpoints are the main integration boundary: the frontend pages likely consume them instead of calling external services directly.
6. Geospatial and mobility data flow
- Charger discovery appears to combine geocoding, reverse geocoding, charger datasets, nearby amenities, and likely distance/route computations.
- The presence of lib/ors.ts points to OpenRouteService-style routing support, while the geocode/reverse-geocode endpoints suggest the app converts user location and destination inputs into map coordinates before querying nearby infrastructure.
7. Infrastructure planning / analytics flow
- The “where to build” feature is likely backed by aggregated spatial and demand data rather than live charger lookup alone.
- Relevant inputs include traffic, EV purchases, district boundary data (data/Districts.geojson, data/india_osm_districts.json), and solar potential endpoints, which together support planning and site selection rather than navigation.
8. Local persistence and caching
- The repo contains both SQLite files and database abstractions (lib/sqlite.ts, lib/db.ts, lib/amenities-cache.ts), showing a caching/persistence layer for expensive geospatial lookups.
- data/amenities_cache.sqlite and data/ev_purchases.sqlite indicate the app stores or preloads structured datasets locally, likely to reduce API latency and dependency on external services.
9. Relational model and migration path
- lib/models/Profile.ts and lib/models/Vehicle.ts suggest structured domain entities for user profiles and vehicle data.
- The migration script scripts/migrate-sqlite-to-postgres.js plus the README’s PostgreSQL mention imply a deliberate move from local SQLite-backed data to a more scalable PostgreSQL deployment.
10. AI / ML service boundary
- The ml-server folder is a separate Python service with a serialized model (solar_energy_model.pkl) and solar_weather_api.py.
- This is a clear architectural boundary: Next.js handles user interaction and orchestration, while Python handles specialized prediction logic for solar/energy estimation.
11. External service integration
- The platform depends on third-party geospatial and environmental APIs, especially for map tiles, routing, weather, charger discovery, and geocoding.
- These integrations are abstracted behind API routes so the frontend has one stable application interface even when the upstream providers change.
12. Deployment/runtime implication
- The repo is a monorepo-style full stack application: React/Next.js for the main runtime, Firebase for auth, PostgreSQL/SQLite for data, and Python for ML.
- For an architecture diagram, the key boundaries are: browser UI → Next.js app routes/API → data stores and external APIs → Python ML service for specialized predictions.
Main entry points: layout.tsx App shell · chargers/route.ts API layer · page.tsx Workflows · solar-potential/route.ts Planning API
Components 20
Frontend app
Next.js App Router pages, shared UI, and client-side state.
- App shell · Root layout and client providers that wrap the application.
app/layout.tsx - Home · Marketing and entry surface for the product.
app/page.tsx - Workflows · Primary user flows for charging, routing, vehicle selection, CO₂, planning, assist, and contact.
app/find-charging/page.tsx - Auth pages · Authentication entry points for users.
app/login/page.tsx - Vehicle setup · Vehicle selection and manual vehicle entry.
app/select-vehicle/page.tsx - Shared UI · Reusable navigation, cards, sections, buttons, and marketing components.
app/(components)/Navbar.tsx - Map UI · Interactive map and route visualization components.
app/(components)/MapClient.tsx - Assistant UI · Chat and assist interface for guided interactions.
app/(components)/ChatbotWidget.tsx - Auth context · Shared authentication and app state provider.
context/AuthContext.tsx
API backend
Route handlers that expose the app's main server-side capabilities.
- API layer · Backend entry point for chargers, amenities, geocoding, routing, traffic, solar, CO₂, vehicles, user, and chat.
app/api/chargers/route.ts - Geo lookup · Geocoding and reverse-geocoding services used to resolve locations.
app/api/geocode/route.ts - Mobility data · Endpoints for charger discovery, nearby amenities, traffic, and EV purchases.
app/api/chargers-all/route.ts - Planning API · Endpoints used by infrastructure planning and impact analysis.
app/api/solar-potential/route.ts - Vehicle API · Vehicle and user profile endpoints including seeding and persistence support.
app/api/vehicles/route.ts
Data & integrations
Local datasets, persistence, Firebase, routing, and external service boundaries.
- Firebase · Client and admin Firebase SDK boundary for authentication and privileged access.
lib/firebase.ts - Local data · Embedded datasets and caches for districts, amenities, and EV purchases.
data/amenities_cache.sqlite - DB layer · SQLite/Postgres access and cached amenities support.
lib/db.ts - Routing engine · Route computation support for map and planning flows.
lib/ors.ts - External services · Upstream providers consumed through the API layer.
ML service
Separate Python service for solar prediction.
- Solar ML · Standalone Python prediction service for solar-related estimates.
ml-server/solar_weather_api.py
Connections 25
- App shell → Home: hosts · The root app shell renders the landing experience.
- App shell → Workflows: wraps · Shared layout/providers support the main workflow routes.
- App shell → Auth pages: wraps · Authentication pages use the same application shell.
- App shell → Vehicle setup: wraps · Vehicle setup runs inside the same Next.js app shell.
- Home → Shared UI: composes · Landing page is built from reusable marketing components.
- Workflows → Shared UI: uses · Workflow pages reuse shared UI primitives.
- Workflows → Map UI: uses · Core workflows depend on interactive map components.
- Workflows → Assistant UI: uses · Assist and chat flows are surfaced through the same frontend.
- App shell → Auth context: provides · Global providers expose auth and app state.
- Auth context → Firebase: authenticates · Client auth flows connect to Firebase.
- API layer → Geo lookup: routes · The API layer exposes geocoding endpoints.
- API layer → Mobility data: routes · The API layer exposes charger, amenities, traffic, and purchase data endpoints.
- API layer → Planning API: routes · The API layer exposes planning and impact analysis endpoints.
- API layer → Vehicle API: routes · The API layer exposes vehicle and profile endpoints.
- Geo lookup → External services: calls · Geocoding requests depend on upstream map/location providers.
- Mobility data → DB layer: reads · Mobility endpoints query cached/local persistence.
- Mobility data → Local data: reads · Endpoints use local spatial and purchase datasets.
- Planning API → Routing engine: computes · Planning endpoints use routing support for distance and path logic.
- Planning API → Solar ML: predicts · Solar-related planning can delegate to the Python ML service.
- Planning API → Local data: reads · Planning combines district and demand datasets from local storage.
- Vehicle API → Firebase: verifies · User and vehicle access uses Firebase auth/admin boundaries.
- Vehicle API → DB layer: persists · Vehicle/profile data is stored through the DB layer.
- DB layer → Local data: caches · SQLite-backed caches and embedded datasets support data access.
- DB layer → External services: hydrates · Persistence layer may be refreshed from external sources.
- Routing engine → External services: calls · Routing relies on an external routing provider.