Azure Palm Beaches



Rather than dealing with latency issues and limitations associated with an IDX system, we opted to store real estate listings on a dedicated Google Cloud SQL database. This allows the client to integrate listings on any website in the future, made it simple to scale, and avoided search criteria restrictions that most IDX providers set. In addition, it has the added benefit of offloading all real estate related mySQL queries to a central Cloud SQL instance, rather than storing real estate listings locally, and adding to the load for the mySQL server on each individual web server.


When new listings get added to the MLS, the real estate agent enters the neighborhood for that listing in a text field, rather than choosing from a pre-defined list of neighborhoods. Because of this, developers must utilize wildcard searches in order to show listings in a specific neighborhood. However using the wildcard method can be inaccurate due to inconsistencies from the agents entering the neighborhood name.

In order to accurately display listings from specific neighborhoods, I chose to utilize a geo-spatial index of GPS polygons for every neighborhood on the website. When the RETS system downloads new listings, it runs a geo-spatial query to determine if the listing is located in any of the neighborhoods in the geo-spatial index, and stores the id of that neighborhood in the row for that listings. This method is significantly more accurate than wildcard searches, and is optimized to prevent the us from constantly running geo-spatial searches when users browse the site.


All real estate listing pages are AJAX driven, to allow users to filter their searches without having to constantly reload the page. When listings are filtered, or additional listings are loaded, a JSON array of listing data is returned, and a pre-compiled handlebars template generates the new markup and adds it to the DOM.