Back to Projects

Case Study

Gold Store

Laravel 5.7 precious-metals marketplace backend from MyWork/Valux/goldStore (PHP 7.3.4+ per composer.json): the same five-route-file pattern as other Valux builds—routes/api.php exposes catalog, settings, categories, products, conversations and messages, plus a token-gated POST for creating products; routes/user.php under /api/user handles login, login-verification, signup, signup-verification, then authenticated resources for bouquets, notifications, messaging, profile, favorites, repost, and pinned items; {lang}/dashboard admin (admin:admin, locale) for banners, complaints, categories, products (with nested productImages), requestProducts, bouquets, vendors, user blocking, and notifications; {lang}/store vendor portal (vendor:vendor) for orders, products, and images. Public web.php is only the default welcome view—buyer UX is API-driven. Mobile auth uses the same Authorization-to-Token table pattern used across Valux marketplace apps, with an extra active user (status == 1) check in middleware. Laravel Collective HTML and mercuryseries/flashy ship in composer.

Laravel 5.7PHPMySQLREST APIMobileAdmin Panel
Valux routing patternToken + status gateTri-role (API, admin, vendor)Messaging APIs
Gold Store cover

Impact

A single backend that separates mobile buyers, staff oversight, and vendor fulfillment—appropriate for a niche metals marketplace without maintaining three separate services.

Problem

Trading-oriented marketplaces need trustworthy listing and messaging flows, vendor-managed inventory, and staff tools that can freeze bad actors—without mixing those concerns into anonymous public pages.

Solution

`RouteServiceProvider::map` registers `api`, `web`, `admin`, `user` (prefixed `api/user`), and `store` route files so JSON clients, operators, and vendors share one deployment. Admin and vendor Blade dashboards use localized prefixes; catalog and social-style features (conversations, reposts, pins) live primarily behind the `Api` and `Api\User` namespaces with `apiLocale` on JSON entrypoints.

Highlighted implementation

Route map (RouteServiceProvider)

PHP
public function map()
{
    $this->mapApiRoutes();
    $this->mapWebRoutes();
    $this->mapAdminRoutes();
    $this->mapUserRoutes();
    $this->mapStoreRoutes();
}

Testing & quality

PHPUnit 5.7 is what composer.json pins for dev; practical QA focused on token rejection, blocked-user responses, verification endpoints, and admin or vendor product image uploads.

Architecture

API Structure

Public API uses `Route::resource` for `home`, `banner`, `settings`, `category`, `subcategories`, `complaints`, `contacts`, `products`, `conversations`, and `messages`, plus an `api:apiUser` group exposing `ProductController@stores`. User API splits verification-heavy auth from a protected block for bouquets, messaging, favorites, repost, and pinned content.

Data Flow

Mobile client loads catalog and threads from guest JSON → authenticated user posts listings or messages through token-checked routes → admins or vendors reconcile products, orders, and imagery in their respective dashboards backed by the same MySQL schema.

Backend Decisions

Custom `api` middleware validates bearer-style tokens and refuses blocked accounts before controller work; keeps gold-store aligned with other Valux apps while adding explicit `status` enforcement; avoids exposing a large public Blade storefront when the product is mobile-first.

Gold Store architecture diagram
High-level diagram of web dashboard, REST API, Laravel layers, and MySQL.

Challenges

Laravel 5.7 is long past upstream support, so security and PHP runtime planning matter for any continued investment. Phone or email verification flows double the auth surface area to regression-test. Vendor and admin must not diverge on product visibility rules.

Technical Decisions

Stayed on the 5.x stack shipped in the repo; relied on Collective HTML for admin forms and Flashy for operator feedback; centralized API locale middleware for consistent JSON errors across Arabic or English strings.