Backend APIBackend developer: built the complete API and data architecture

ShareABite

Backend system for a food donation platform connecting restaurants and eateries with communities to reduce food waste.

Overview

Food waste in the restaurant industry is a coordination problem: surplus food exists, communities need it, but there's no reliable system connecting them. ShareABite is the backend infrastructure that makes that coordination work: role-separated access, consistent API contracts, and a data model built for real operational workflows.

The API covers authentication, role management, donation workflows, and pickup request handling, all with a consistent response structure.

The architecture supports three distinct client types: a restaurant portal, an eatery dashboard, and an admin panel, each with separate permissions managed through role-based access control.

Goal

Three distinct client types (Admin, Eatery, Restaurant), each with different data access requirements. The goal was clean role separation at the API layer, so each client sees exactly what it should and nothing else.

  • Role-based access control for Admin, Eatery, and Restaurant users
  • JWT authentication with protected routes and token validation middleware
  • MongoDB schemas for users, donations, and pickup requests
  • RESTful APIs with consistent response formats throughout
  • Proper HTTP status codes and authorization checks on every route

Outcome

A complete API covering all core workflows: authentication, role separation, donation listings, and pickup requests. Consistent response contracts and clean architecture, ready for team handoff.

  • Complete authentication system with JWT and protected routes
  • Three separate role types with distinct permission sets
  • Donation listing and pickup request workflows
  • Consistent API response format across all endpoints
  • Clean, well-structured codebase ready for team handoff

Tech Stack

  • Node.jsNode.js
  • Express.jsExpress.js
  • MongoDBMongoDB
  • JWTJWT

Technical Decisions

01

Role-based JWT middleware over per-route authorization logic

Three client types needed different permission sets without a complex permissions table. JWT claims carry the role; a single middleware layer checks it before the route handler runs. Stateless, simple, and consistent. Adding a new protected route required no changes to the auth logic.

02

MongoDB for donation listing schemas

Food donation listings have variable fields: item types, quantities, expiry windows, dietary flags, and pickup availability. A flexible document structure handled this better than forcing a rigid relational schema onto inherently semi-structured listing data.

03

Consistent API response envelope across all endpoints

All endpoints return { success, data, message }. With three client types and a planned team handoff, inconsistent response shapes would have caused brittle frontend parsing. A shared envelope made integration predictable and reduced coordination overhead between the API and consuming clients.

3

Auth roles

4

Entity schemas

5

Resource groups

Unified

Response contract