ResQPlate

Rescue surplus food. Coordinate delivery. Measure real impact.

ResQPlate is a responsive food-rescue platform connecting donors, receivers, and volunteers through secure role-based workflows, live rescue data, maps, tracking, and impact reporting.

Open live application · Features · Workflow · Setup · Deployment

ResQPlate is a pilot-stage application. Review PRODUCTION_READINESS.md before an unrestricted public launch.

Usable food is frequently discarded because donors and receivers lack a fast, transparent coordination channel. ResQPlate turns surplus food into a trackable rescue workflow:

flowchart LR
  D[Donor posts surplus food] --> L[Live donation listing]
  L --> R[Receiver claims food]
  R --> V[Nearby volunteer matched]
  V --> P[Pickup and delivery]
  P --> I[Impact recorded]

The platform combines a polished public experience with authenticated workspaces designed around the responsibilities of each participant.

All screenshots show the current application in light mode.

_{Focused rescue messaging, direct role actions, and an interactive rescue-plate game.}

About ResQPlate	Contact experience
Secure sign in	Role-based signup

1. Create an account and select the Donor role.
2. Open Post food and provide the food details, meal count, image, pickup address, and expiry window.
3. ResQPlate validates the form, geocodes the address, uploads the image, and creates the Appwrite record.
4. Monitor reservations, active rescues, completed deliveries, analytics, and impact from the dashboard.
5. Cancel an active donation through the secure server workflow when necessary.

1. Create an account with the Receiver role.
2. Browse available, unexpired donations or use the matching experience.
3. Add suitable donations to the rescue cart.
4. Confirm a complete delivery address at checkout.
5. The server workflow verifies availability, reserves the donations, records receiver ownership, and removes them from public availability.
6. Follow the rescue from reservation through delivery using Order Tracking.

1. Select the Volunteer role and configure availability, location, and meal capacity.
2. The secure Appwrite Function finds eligible rescues and ranks volunteers using distance, capacity, reliability, and urgency.
3. Accept or decline private assignments.
4. Open donor directions and the verified donor-to-receiver route.
5. Confirm delivery only after a receiver has claimed the food.

posted (pending, no receiver)
        ↓
reserved (pending, receiver assigned)
        ↓
delivered (completed)

cancelled closes an active rescue without marking it delivered

Availability is derived from persisted Appwrite data. A donation is available only when it is pending, unclaimed, valid, and unexpired.

flowchart TD
  U[Donor / Receiver / Volunteer] --> UI[React + Vite client]
  UI --> ROUTER[React Router]
  UI --> AUTH[Auth context]
  UI --> CART[Cart context]
  UI --> THEME[Theme context]

  ROUTER --> PUBLIC[Landing / About / Contact / Auth]
  ROUTER --> DASH[Protected role workspaces]
  ROUTER --> FLOW[Cart / Checkout / Tracking / Map]

  AUTH --> AW[Appwrite]
  DASH --> AW
  FLOW --> AW

  AW --> ACCOUNT[Authentication]
  AW --> DB[(Pickup and volunteer data)]
  AW --> STORAGE[(Donation images)]
  AW --> REALTIME[Realtime events]
  AW --> FUNCTION[Secure rescue workflow]

  UI --> MAPS[OpenStreetMap + OSRM]
  UI --> BOT[Server-side ResQBot proxy]
  BOT --> GROQ[Groq - optional]

• Browser code reads only VITE_ configuration values, which are public by design.
• Sensitive AI credentials remain server-side.
• Pickup claims, donor cancellations, volunteer responses, and delivery completion use the authenticated Appwrite Function.
• Pickup records allow authenticated creation and reading but do not grant public/client update access.
• Receiver identity is stored with a claimed rescue.
• Volunteer notifications use private document permissions.

ResQPlate_frontend/
├── .github/workflows/          Appwrite health and console reminders
├── appwrite.config.json        Versioned backend schema and function config
├── functions/
│   └── rescue-workflow/        Secure claims, cancellation, matching, and delivery
├── frontend/
│   ├── api/                     Server-side ResQBot proxy
│   ├── public/                  Logo, sitemap, screenshots, verification assets
│   ├── src/
│   │   ├── components/          Marketing UI, navigation, map, cards, ResQBot
│   │   ├── context/             Authentication, cart, and theme state
│   │   ├── hooks/               Tracking, alerts, and volunteer data
│   │   ├── layouts/             Responsive dashboard shell
│   │   ├── pages/               Route-level application screens
│   │   └── services/            Appwrite, workflow, geocoding, and routing logic
│   ├── tests/                   Role and workflow regression tests
│   ├── .env.example             Safe configuration template
│   ├── vercel.json              SPA rewrites and cache headers
│   └── package.json             Commands and dependencies
├── PRODUCTION_READINESS.md
└── README.md

• Node.js 20.19+ or 22.12+
• npm
• An Appwrite project
• Optional Groq and EmailJS accounts

git clone https://github.com/salonyranjan/ResQpla8.git
cd ResQpla8/frontend
npm ci
cp .env.example .env
npm run dev

Windows PowerShell:

Copy-Item .env.example .env

Open the address printed by Vite, normally http://localhost:5173.

Start with frontend/.env.example.

Minimal example:

VITE_APPWRITE_ENDPOINT=https://fra.cloud.appwrite.io/v1
VITE_APPWRITE_PROJECT_ID=
VITE_APPWRITE_DATABASE_ID=
VITE_APPWRITE_PICKUPS_COLLECTION_ID=pickups
VITE_APPWRITE_BUCKET_ID=
VITE_APPWRITE_VOLUNTEER_FUNCTION_ID=

Never commit frontend/.env. Every VITE_ value is bundled into browser code, so secrets must not use that prefix.

The repository includes the versioned configuration in appwrite.config.json.

1. Log in with the Appwrite CLI.
2. Link or initialize the intended Appwrite project.
3. Push the table configuration.
4. Deploy and activate functions/rescue-workflow.
5. Configure the Function variables and document read/write scopes.
6. Add localhost and every deployed hostname under Appwrite Console → Project → Platforms → Web.
7. Copy the project, database, collection, bucket, and Function IDs into the frontend environment.

The rescue Function requires these server variables:

RESQPLATE_DATABASE_ID
RESQPLATE_PICKUPS_COLLECTION_ID
RESQPLATE_VOLUNTEERS_COLLECTION_ID
RESQPLATE_NOTIFICATIONS_COLLECTION_ID

Do not restore anonymous pickup creation or public update permissions. Server-side workflows are the authorization boundary for rescue state changes.

Unknown routes safely redirect to the landing page.

cd frontend
npm test
npm run lint
npm run build
npm run preview

Before release, manually verify complete donor, receiver, and volunteer journeys using dedicated test accounts.

ResQPlate can be deployed to Vercel or another static SPA host.

Deployment checklist:

1. Add the frontend environment variables to the hosting provider.
2. Keep GROQ_API_KEY server-side.
3. Deploy and activate the Appwrite rescue Function.
4. Register the production hostname as an Appwrite Web platform.
5. Confirm SPA fallback behavior for deep links.
6. Test signup, login, posting, image upload, claiming, routing, delivery, and logout.
7. Configure APPWRITE_ENDPOINT and APPWRITE_PROJECT_ID for the GitHub health workflow.

The included frontend/vercel.json provides SPA rewrites and immutable caching for built assets.

1. Fork the repository.
2. Create a focused branch.
3. Make a small, documented change.
4. Run tests, lint, and the production build.
5. Open a pull request describing the user-facing impact.

Developed and maintained by Salony Ranjan.

Issues and contributions are welcome in the ResQPlate repository.