ស្ថាបត្យកម្ម

សេចក្តីសង្ខេបជាភាសាខ្មែរ [km-review]

LifeLink KH មានកម្មវិធីពីរ (កម្មវិធីទូរស័ព្ទ Flutter និងគេហទំព័រ Next.js) និងគម្រោង Firebase មួយ ដែលដំណើរការដោយឥតគិតថ្លៃ។ កម្មវិធីអានទិន្នន័យពី Firebase ដោយផ្ទាល់ ហើយ Security Rules ជាអ្នកការពារ។ អ្វីដែលកម្មវិធីមិនអាចសរសេរដោយខ្លួនឯងបាន (ដូចជាការផ្គូផ្គង និងការផ្ញើសារជូនដំណឹង) ដំណើរការលើម៉ាស៊ីនមេរបស់គេហទំព័រ។ ព័ត៌មានលម្អិតខាងក្រោមជាភាសាអង់គ្លេស។

LifeLink KH is two clients and one Firebase project, running at $0.

            Firebase (lifelinkkh, asia-southeast1, Spark plan — no card)
     ┌──────────────────────────────────────────────┐
     │  Firestore + Security Rules   Firebase Auth  │
     │  Cloud Messaging (FCM)                       │
     └──────────────────────────────────────────────┘
          ▲  Firebase SDK (reads)     ▲  REST (admin) + Admin SDK (functions)
          │                           │
     Flutter app ──── POST /api/functions/{name} ────> Next.js portal, Vercel sin1
  (donors, requesters)  createRequest · respondToMatch   (public pages + admin +
     → APK               deleteAccount                    reviewRequest · confirmDonation)

Layer	Technology	Source
Mobile	Flutter (Android; iOS build-only), Riverpod, go_router, cloud_firestore	`mobile/`
Web	Next.js App Router, TypeScript, Tailwind, shadcn/ui, next-intl	`frontend/`
Server logic	The portal's own Node server on Vercel Hobby (`frontend/src/server/`)	ADR 0010
Data	Cloud Firestore + Security Rules, one emulator test per rule	`firebase/`
Identity	Firebase Auth: Google/Facebook in the app, Google or password for admins	ADR 0002, DEC-017
Push	Firebase Cloud Messaging, in the donor's own language	—
Location	`geolocator`, no map widget	DEC-004, ADR 0003

The rules that hold it together

Clients read Firebase directly; the Security Rules are the only gate. Anything a client must not write goes through a function on the portal's server, and the rules refuse that write to every client.
Five functions (POST /api/functions/{name} with the caller's Firebase ID token):
- createRequest (app): writes a request as PENDING;
- reviewRequest (admin): approve, which runs matching and push, or reject;
- respondToMatch (app): a donor's accept or decline;
- confirmDonation (admin): records the donation and starts the cooldown;
- deleteAccount (self): removes personal data and keeps anonymous counts.
Matching selects compatible, available, eligible donors within 10 km of the hospital, nearest first. ABO/Rh compatibility is a fixed lookup table, never user input (ADR 0004). Donors with no GPS still match by district.
Offline first: the app reads through Firestore's offline cache, and a donor's answer is queued on the phone until it can be sent.

The rules that hold it together​

Read further (in the repo)​

The rules that hold it together

Read further (in the repo)