How lakshan2906/nexusaid---project works
1. Overall system shape
- NexusAid is a single-page React application with a thin client-side architecture.
- There is no custom server code in the repo; the main runtime boundaries are the browser UI, Firebase services, and the external Gemini API.
- The repo also contains a built dist/ bundle, confirming it is deployed as a static web app.
2. Application bootstrap
- src/main.tsx is the entry point and mounts App.tsx.
- App.tsx is the top-level composition layer that likely coordinates the main experience and switches between the three role-specific views.
3. Role-based UI partitioning
- The main user-facing boundary is split into:
- VictimView.tsx for emergency request submission,
- NgoView.tsx for response/coordination,
- DeveloperView.tsx for oversight, analytics, or system administration.
- This suggests a single app with multiple operational consoles, not separate apps.
4. Emergency intake and AI processing
- The core workflow starts in the victim-facing view where unstructured distress text is entered.
- src/services/geminiService.ts is the AI boundary: it sends that raw text to Google Gemini and converts it into structured emergency data.
- The README’s example output shows the AI extracting fields such as resources, people count, injured count, urgency, category, and a recommended NGO.
5. Shared state and persistence
- src/lib/firebase.ts is the Firebase initialization layer.
- src/lib/firestoreUtils.ts likely wraps Firestore reads/writes used by all views.
- Firestore is the main shared datastore for requests and response coordination, enabling the NGO and developer views to see the same operational data.
6. Security boundary
- firestore.rules is the main enforcement point for data access control.
- security_spec.md indicates the repo includes an explicit security model/documentation layer, which is important because the app handles emergency and potentially sensitive data.
- If Firebase Auth is used, it would be configured through firebase.ts, but there is no separate backend auth service in the tree.
7. Mapping and routing subsystem
- src/components/RoutingMachine.tsx is a dedicated geospatial component.
- The README and tech stack indicate Leaflet / React-Leaflet / Leaflet Routing Machine are used to visualize and compute relief routes between NGO resources and victims.
- This subsystem is likely embedded in operational dashboards rather than being a standalone feature.
8. Location acquisition
- src/services/locationService.ts is the boundary for browser/location input.
- It likely abstracts geolocation access and converts the device position into coordinates used by the mapping and routing layer.
- This is a separate concern from AI parsing: one service interprets text, the other gets physical location.
9. Frontend structure and styling
- src/index.css contains global styling; the app is a client-rendered UI.
- The presence of a Vite config and TypeScript config indicates a modern frontend build pipeline, but they do not introduce server-side runtime layers.
- The screenshots and README imply a dashboard-style UX with role-specific operational screens.
10. Deployment and hosting
- firebase.json, .firebaserc, and the presence of dist/ show the app is deployed through Firebase Hosting.
- The hosting layer serves the static SPA, while Firestore provides the shared backend data plane.
- Any real-time behavior comes from client-to-Firestore updates rather than a custom API server in this repository.
11. Key data flow to show in an architecture diagram
- Victim input → VictimView → geminiService → structured emergency payload → Firestore.
- NGO dashboard → Firestore subscription/read path → prioritized request list and coordination state.
- Location service → mapping/routing component → route visualization for response planning.
- Developer view → Firestore/aggregated app data for oversight.
12. Important architectural note
- The product vision emphasizes low-connectivity and decentralized disaster response, but the code surface in this repo is primarily a Firebase-backed web client.
- So the most accurate diagram should center on browser SPA + Gemini API + Firestore + Firebase Hosting, with offline/decentralized behavior treated as a goal unless additional implementation exists outside this tree.
Main entry points: firestoreUtils.ts Firestore utils · App.tsx App shell · VictimView.tsx Victim view · geminiService.ts Gemini service
Components 16
Browser SPA
Client-side React application and UI consoles.
- Entry point · Mounts the React application.
src/main.tsx - App shell · Top-level UI composition and role switching.
src/App.tsx - Victim view · Collects emergency requests from affected users.
src/views/VictimView.tsx - NGO view · Coordinates response, prioritization, and operations.
src/views/NgoView.tsx - Developer view · Provides system visibility and administrative oversight.
src/views/DeveloperView.tsx - Location service · Reads browser/device location for response workflows.
src/services/locationService.ts - Routing machine · Renders and computes relief routes on the map.
src/components/RoutingMachine.tsx - Gemini service · Transforms distress text into structured emergency data.
src/services/geminiService.ts - Firestore utils · Shared reads and writes against the operational datastore.
src/lib/firestoreUtils.ts
External Services
Third-party APIs and shared cloud data services used by the app.
- Firebase init · Initializes Firebase client services used by the SPA.
src/lib/firebase.ts - Firestore · Primary store for requests, coordination state, and views.
- Gemini API · External model endpoint used for emergency text structuring.
Delivery & Security
Static hosting, build artifacts, and access control boundaries.
- Firebase Hosting · Serves the built single-page app.
firebase.json - Firestore rules · Enforces data access control for the shared datastore.
firestore.rules - Security spec · Documents the app's security model and constraints.
security_spec.md - Built app · Compiled static bundle deployed as the hosted SPA.
dist/index.html
Connections 18
- Firebase Hosting → Built app: serves · Hosting delivers the compiled web app.
- Entry point → App shell: boots · Entry point mounts the root application shell.
- App shell → Victim view: shows · App shell routes to the victim-facing workflow.
- App shell → NGO view: shows · App shell routes to the NGO operations view.
- App shell → Developer view: shows · App shell routes to the developer oversight view.
- Victim view → Gemini service: parses · Emergency text is structured through the AI boundary.
- Gemini service → Gemini API: calls · Service forwards text to the external Gemini endpoint.
- Victim view → Location service: requests · Victim workflow can capture device location.
- Location service → Routing machine: feeds · Coordinates support route visualization and planning.
- Routing machine → NGO view: embeds · Routing UI is used inside operational response screens.
- Gemini service → Firestore utils: writes · Structured emergency payloads are persisted through shared data access.
- Firestore utils → Firebase init: uses · Data access layer relies on Firebase client initialization.
- Firebase init → Firestore: connects · Firebase client reaches the shared Firestore backend.
- Firestore utils → Firestore: reads/writes · Operational data is stored and retrieved from Firestore.
- NGO view → Firestore utils: reads · NGO dashboard consumes shared request and coordination data.
- Developer view → Firestore utils: reads · Developer view uses the same operational datastore for oversight.
- Firestore rules → Firestore: guards · Security rules constrain access to Firestore data.
- Security spec → Firestore rules: documents · Security documentation describes the access model.