HouseSearch: Map-Based Rental Listing Search

HouseSearch Maps Public Rentals Instead of List Pages

HouseSearch addresses a practical problem in rental hunting: text listings force users to reconstruct location, commute, and neighborhood relationships themselves. The repository describes a crawler and map-driven platform that collects publicly available rental information, processes it, stores it in a database, and places supported listings on a map through the Amap API. That changes the unit of comparison from a long list of posts to a geographic view in which a prospective tenant can inspect where a rental sits relative to other results.

The intended audience is people searching for rental housing, especially users who also need to estimate travel from an address to a company. According to the README, the interface can calculate transit-and-map or walking routes and provide estimated travel times. It also supports saving individual properties as favorites and filtering some listings by price. These functions make sense when commute time is part of the decision, although the documentation does not explain how fresh route estimates are, how addresses are geocoded, or whether every source survives the geocoding process.

The README names supported or implemented sources including 豆瓣租房小组, Zuber 合租, 蘑菇租房, 小红书, 贝壳租房, 房天下, and 上海互助租房. It also describes the crawler as running continuously, but it does not publish a source health report, listing retention policy, duplicate-removal method, or per-source update schedule. A map result therefore represents processed public data, not a guarantee that a landlord still has the property or that the advertised terms remain current. Users would still need to confirm price, availability, address, lease conditions, and contact details through the original listing where possible.

HouseSearch Crawls, Stores, and Resolves Listings Geographically

The repository is split into a Vue.js user interface and a.NET Core backend. Within House-Map.Crawler, the README distinguishes the Crawler project, which contains crawler logic, from the API project, which exposes the Web API consumed by the web experience. This separation gives each side a defined responsibility, but it also means deployment requires coordination between collection services, persistence, caching, search, and the frontend.

MySQL is the primary relational store, Redis is used for caching, and MongoDB handles keyword queries. The repository includes a database structure file named Dump20220410_housemap.sql and a Beijing-specific crawler configuration file named beijing-config.sql. Those artifacts are more useful than a high-level architecture diagram because they expose part of the expected data and configuration layout. However, the README does not connect every table to a crawler or API operation, so the exact import sequence cannot be derived from the documentation.

The likely data path is visible from the named components: source crawlers obtain public rental information, processing and analysis convert it into stored records, the API reads application data, and the Vue interface renders supported locations through Amap. The final stage also brings in route calculation for transit-and-map or walking navigation. The documentation does not state whether the crawler uses official platform APIs or page access for each named source, nor does it define retry behavior, rate limits, proxy configuration, failure queues, or freshness markers. Those omissions matter for an operator because a functioning UI cannot compensate for a crawler that is blocked, stale, or writing malformed coordinates.

The source-specific configuration is another boundary. The presence of `beijing-config.sql` suggests that region or source setup is data-driven, at least for Beijing. The README does not say whether adapting the system to another city is a matter of copying that file, changing coordinates, adding crawler records, or editing compiled code. It should not be treated as a ready-made nationwide deployment kit without inspecting those configuration files directly.

Using the House2048 Web Service and WeChat Mini Program

The repository does not provide a conventional local installation tutorial in the README, and it does not give verified commands for building either House-Map.UI or House-Map.Crawler. It directs readers to 使用教程.md. Inventing dependency versions, environment variables, migration commands, or startup flags would be misleading.

For the lowest-friction first use, the documented public entry point is the hosted service at https://web.house2048.cn. Open that address in a browser, allow the map interface to load, and use its rental search, map display, price filtering where supported, favorites, and address-to-company route features. The expected visible result is a map-oriented rental interface rather than a conventional text-only results page. The README does not specify the exact button labels or interaction sequence, so this tutorial does not claim controls that are not documented.

HouseSearch also offers access through a WeChat mini program. The stated procedure is to follow the 人生删除指南 public account, search for `House2048` in the mini program, and open the listed property experience. No mini-program version, release date, compatibility statement, or offline fallback is given. A prospective user should therefore choose between the website and mini program based on availability rather than assume they expose identical features.

Self-hosting is a different task and should not be confused with opening the hosted site. The documented stack includes.NET Core 3.2, Vue.js, MySQL, Redis, MongoDB, and Amap API access. Before attempting a local build, read 使用教程.md and the project-specific files in House-Map.Crawler. Confirm runtime availability for.NET Core 3.2, restore the database using the repository's SQL as directed by the tutorial, and establish which crawler configuration applies to the intended city. The README does not confirm that any of those prerequisites are currently obtainable or still aligned with upstream services.

HouseSearch Deployment Carries Legacy Stack and Operations Costs

The repository is not archived, and its last push was on 2026-10-09. That is recent repository activity, but it does not by itself establish release readiness. The repository has no GitHub releases, so there is no published release artifact or upgrade series to use as a stable deployment boundary. Operators should distinguish a recent source update from a supported production release.

The backend is described as .NET Core 3.2. That version is an explicit maintenance and upgrade concern because it fixes the runtime family expected by the documented code. The README also says that Jenkins was deprecated in 2019 in favor of Gitlab CI and Kubernetes. Based on that statement, the old Jenkins path should not be treated as the preferred deployment method. At the same time, the repository summary does not show the exact Gitlab CI file, Kubernetes manifests, image names, secret handling, or current deployment procedure. The apparent move to newer infrastructure does not modernize the application runtime or prove that the automation still works.

The data services add operational scope. MySQL stores the core records, Redis caches data, MongoDB supports keyword lookup, and separate crawler and API processes handle different tasks. A local or private deployment therefore needs compatible versions, persistent storage, service discovery or fixed addresses, database initialization, credentials, log access, and backup decisions. None of those version and recovery requirements are specified in the README. This is a meaningful cost for a small team that wanted only a map interface.

HouseSearch is licensed under LGPL-3.0. For organizations considering modification or redistribution, the license file governs obligations and compatibility, particularly when distributing a modified library or application. This is a licensing boundary to review with the organization's own policy, not legal advice. The README does not state separate terms for the hosted service, crawled content, Amap integration, or third-party listings.

HouseSearch Differs from Search-Only Rental Aggregators

A realistic alternative is a conventional rental search site that offers a text list, filters, and direct links to each listing without requiring the reader to operate a crawler stack. The difference is architectural and operational. HouseSearch collects public listing information through its own crawler components, normalizes it into its own databases, and exposes the result through a map and route-aware interface. A search-only aggregator leaves collection and presentation to its service operator, so a prospective tenant avoids running .NET Core, MySQL, Redis, MongoDB, and crawler configuration.

Another alternative is a general-purpose map service with manually saved rental URLs or addresses. This does not automate rental discovery or persist scraped listings, favorites, and price filters in the same application, but it can use current map data without maintaining source-specific crawlers. HouseSearch is more relevant when automated geographic aggregation and commute comparison are central. It is less relevant if a small candidate list is enough.

HouseSearch is the wrong tool when commercial hosting, source stability, or operational simplicity dominates. The crawler depends on external platforms and undocumented collection behavior, while routing depends on Amap. Changes to a source's pages, access controls, data format, or terms can invalidate collection even if the rest of the application remains online. The README does not describe a stable upstream API contract or a freshness guarantee for each named source.

It is also a poor fit for compliance-sensitive environments that require a clear retention policy for public posts or evidence that each listing can be lawfully collected and redistributed. The repository calls the inputs public rental information, but that description alone does not answer jurisdiction-specific legal questions. The correct adoption boundary is therefore operational transparency, not an assumption that public visibility removes all downstream obligations.

HouseSearch Listing and Routing Claims Need Verification

The strongest case for HouseSearch is geographic comparison. A user can see supported listing positions on an Amap map, retain favorites, filter some prices, and calculate a route from an address to a company. That is more decision-oriented than reading disconnected posts, assuming the coordinates and listing metadata are correct. The source breadth named in the README also suggests aggregation across several rental communities and platforms rather than dependence on one site.

The weakness is the distance between interface capability and data assurance. The README says listings are obtained by continuous crawling and stored after processing, but it does not state how old each record can be, how partial crawls are represented, or whether users can see a crawler's last successful run. It also does not explain how duplicate posts are merged, conflicting prices are resolved, or removed properties are purged. A displayed marker can therefore look authoritative while the underlying post has changed.

Route calculation has a different dependency chain. The application needs an origin, a company destination, usable listing or address coordinates, and working Amap services. The README mentions transit-and-map or walking navigation and estimated duration, but it does not document supported regions, rate limits, fallback behavior, or whether traffic conditions affect the estimate. Users should compare the route with the listing address before relying on it for a viewing appointment.

The maintenance record needs equally direct interpretation. HouseSearch is not archived, and its last push was on 2026-10-09, but the absence of GitHub releases leaves adopters without a documented upgrade path. A recent commit is useful evidence that repository activity continued; it is not evidence that every source crawler, dependency, database script, and deployment manifest is current. Reviewing the repository's `日常更新.md` and 使用教程.md is the first project-specific check for operational expectations.

Editorial conclusion

HouseSearch suits prospective tenants who want rental listings placed geographically and need to compare a home with a workplace. It is a weaker choice for developers expecting current installation documentation, isolated infrastructure, or immediate access to reliable listing coverage. Before adoption, inspect 使用教程.md, identify the listed source-specific crawler configuration, verify access to Amap API credentials and mapping services, and determine whether the 2019 GitLab CI and Kubernetes deployment path still matches your environment.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. liguobao/HouseSearch on GitHub
4. Project website
5. README