Case study

Having — API & operations platform

Long-lived product with mobile-facing REST APIs, internal dashboards, payments, and moderation: Laravel core plus a separate React admin.

Laravel PHP services Repositories API v1 React + Vite Paymob Firebase

What it is

Consumers hit versioned JSON APIs (properties, reels, support, history, etc.) while staff use a dedicated admin-dashboard SPA. The backend concentrates integrations (e.g. Paymob), rules, and reporting; documentation in-repo covers routes, deployment, and response shapes.

Architecture

Classic modular Laravel monolith with clear boundaries: HTTP controllers stay thin, domain logic sits in named services, and data access goes through repository interfaces with Eloquent implementations. Dashboard features have their own controllers and services under a dedicated namespace.

┌─────────────┐ ┌─────────────┐ ┌──────────────────┐ │ Mobile apps │ │ React admin │ │ Webhooks / APIs │ └──────┬──────┘ └──────┬──────┘ └─────────┬────────┘ │ REST (api/v1…) │ REST / session │ Paymob, etc. ▼ ▼ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Laravel — Controllers → Services → Repositories → Models │ │ Auth: app users + Firebase paths · Unified API responses │ └──────────────────────────────────────────────────────────────┘ │ ▼ MySQL / cache / queues

Highlights

URI versioning keeps mobile clients stable while the core evolves.
Service + repository layering keeps complex flows testable and avoids fat controllers.
Split UI: React admin can iterate on ops UX without rewriting consumer APIs.
Strong fit for integrations (payments, auth) in one auditable codebase.