Architecture overview

How Nigraan's parts fit together, from the two apps and the shared Supabase backend to the scheduled data jobs and hosting.

Nigraan is two front ends over one backend. The website (a React single-page app) and the mobile app (Flutter) both talk directly to the same Supabase project. Scheduled jobs on GitHub Actions keep the official data and the facility map fresh. The website is served as static files from Vercel.

The parts

  Website (React, Vercel)          Mobile app (Flutter)
          │                                 │
          │   HTTPS — publishable key       │
          │   + the signed-in user's token  │
          └──────────────┬──────────────────┘
                         ▼
        Supabase: PostgreSQL + PostgREST + Auth
        (row-level security decides who sees what)
                         ▲
                         │  service key (GitHub secret)
     GitHub Actions: NDMA/PDMA ingest (3×/day)
                     OpenStreetMap facilities (daily)

  Browsers also call Open-Meteo directly for the weather forecast,
  and load map tiles from Esri and OpenStreetMap.

Part	Technology	Documentation
Website	React 18, TypeScript, Vite, Tailwind CSS, Leaflet	Frontend
Backend	Supabase: PostgreSQL, PostgREST, Supabase Auth	Backend
Tooling and scripts	Node.js, npm, Vitest, ESLint	JavaScript stack and tooling
Official data and facilities	Node.js jobs on GitHub Actions	Data pipeline
Hosting and search engines	Vercel, prerendered HTML, sitemap	Hosting, deployment and SEO
Who may do what	Roles enforced in the database	Roles and security
Quality	Unit, browser and load tests	Testing and quality

How a report travels

1. A signed-in user submits a report from the website or the app. It is inserted into the map_records table with no review decision.
2. Row-level security keeps it out of every public read, so no visitor can see it.
3. A reviewer approves it, which stamps reviewed_at and reviewed_by; or refuses it, which records a reason and keeps it hidden.
4. Approved records are what the public maps, the data table, the PDFs and the donor dashboard read.

The review gate lives in the database, not in either app, so the two clients cannot disagree about what is public.

Design principles

• One source of truth. Both apps read and write the same tables; neither has a private backend.
• The database is the gate. Every permission is enforced with row-level security and database functions. The apps hide what a role cannot do, but they are not what stops it.
• Nothing public without review. Community data is published only after a person approves it.
• Honest data. Official figures link to their source documents, and community records carry who uploaded and who approved them.
• Fast on weak connections. Map reads exclude photos and voice notes; heavy pages load on demand.

← All technical documentation