Property Discovery Platform

The problem

Property-search interfaces must coordinate multiple views of the same data without allowing the map, filters, selected result, and persisted records to drift out of sync. I built this prototype to explore that coordination across a React frontend and a WordPress backend.

Architecture

Search query
   ↓
React Router
   ↓
External listing API → Axios request
   ↓
Redux Toolkit store
   ↓
Listing sidebar ↔ selected property ↔ Google Map markers
   ↓
WordPress AJAX endpoint
   ↓
Property custom post type + post metadata

Frontend decisions

Shared listing results live in Redux Toolkit because they are consumed by the sidebar, filters, and map. Selected-property state, map center, and filter controls remain local to the interface that owns them. This keeps global data centralized without turning every transient interaction into global state.

A reference map connects each listing card to a property identifier. Selecting a marker can therefore highlight and scroll the corresponding listing into view, while selecting a card recenters the map and opens the related information window.

Backend integration

The PHP layer receives serialized listing data through WordPress AJAX, decodes and sanitizes the payload, creates a property post, and stores structured fields as metadata. The original prototype also explored remote image sideloading into the WordPress media library.

What I would harden for production

The portfolio version documents the original architecture and its limitations. A production implementation would proxy external requests server-side, move credentials out of browser bundles, require authenticated writes and nonces, validate allowed remote hosts, deduplicate listings by provider ID, and add schema validation, rate limiting, automated tests, and structured failure states.