TrendRadar review: multi-platform hot-topic filtering for GitHub users

Why TrendRadar focuses on filtered Chinese hot lists

TrendRadar addresses a specific information problem: popular topics are spread across many Chinese platforms, while a user usually wants only a small set of subjects, such as `AI`, `比亚迪`, or an industry policy. The repository description says it monitors 35 platforms. The README names examples including 今日头条, 百度热搜, 微博, 抖音, 知乎, bilibili, 财联社, 澎湃新闻, 华尔街见闻, 凤凰网, and 贴吧. The intended users are investors and traders, content creators, company managers, public-relations teams, and ordinary readers who follow current affairs.

The project is not presented as a general news database. Its documented workflow is centered on collecting hot-list items, matching them against configured keywords, counting repeated appearances, and presenting the result as a notification or web report. The repository description also says it can automatically generate a hot-topic analysis report, although the README does not define the analysis algorithm or report schema. That distinction matters for adoption: TrendRadar is closer to an automated monitoring and distribution layer than to a research archive.

The source data comes from the `newsnow` API, not from TrendRadar's own platform-specific collection code. This keeps the project small and makes it easier to deploy through a fork, but it also means that availability and data behavior depend on an external project. The README does not specify a rate limit, retry policy, historical retention period, or guarantee that every listed platform will remain available.

TrendRadar's collection, filtering, and notification path

Based on the repository layout and README, the practical path has four parts. The project collects trending entries through the `newsnow` API, applies configured keywords to items, tracks repeated appearances over the monitoring period, and renders the results for a web page or notification channel. The repository contains `main.py`, `config/`, `api/`, `output/`, and an `index.html` entry point. Its Python dependencies include `requests`, `pytz`, `PyYAML`, and `playwright`.

The README gives two output URLs for deployments that include the added API layer:

https://your_domain/api/trends.json

The first is described as a trends API endpoint. It also documents an image report at:

https://your_domain/img/news.jpg

The README does not document authentication, cache headers, response fields, rate limits, or error responses for either endpoint. Callers therefore cannot assume that these URLs form a stable public API contract or that a response will be available after a failed collection run.

TrendRadar supports three notification strategies. The README associates `incremental` with newly appearing information, `current` with current hot topics, and `daily` with a complete daily report. It also supports a time window, such as `9:00-18:00`, with either repeated delivery inside the window or one delivery during it. This is a scheduling layer, not an alerting system with documented incident severity or delivery guarantees. A scheduled run can still fail when the upstream API, GitHub Actions environment, or notification service is unavailable.

Fork deployment and the first usable configuration

The README presents GitHub Pages as the lowest-friction deployment route: fork the repository, open the fork's GitHub Settings, and enable GitHub Pages. It also lists GitHub Actions and Docker deployment. The repository includes a `docker/` directory, but the README does not give a complete Docker command, image name, port mapping, or environment-variable list. It would therefore be unsafe to invent those operational details.

The first useful configuration is keyword selection. Add the topics that matter to your work in the project's frequency-word configuration. The README names `frequency_words.txt` as the input for frequency terms and states that an empty file causes all collected news to be pushed, subject to notification size limits. It also recommends reducing the number of monitored platforms when sending every item to a phone. Broad monitoring can therefore exceed a notification channel's payload limit even when keyword filtering is not required.

For messaging, the supported channels are 企业微信, 飞书, 钉钉, and Telegram. The v2.0.4 release notes add a security warning: webhooks must not be public. The notes recommend storing webhooks in GitHub Secrets rather than placing them in `config.yaml`. They also recommend deleting and regenerating any webhook that has already been exposed. This is a configuration responsibility that remains with the operator. The README does not document token rotation, notification retries, or what happens when a channel returns an error.

The documented upgrade path is unusually specific. For a minor update, the README tells users to replace the fork's `main.py` with the project's current file through the GitHub web editor. For a major upgrade from `v1.x` to `v2.0`, it recommends deleting the existing fork and forking again to avoid configuration conflicts. The README identifies the current project version as `v2.1.0`, while the repository has no GitHub releases.

TrendRadar's dependency and payload limits

The main limitation is dependency concentration. TrendRadar relies on `newsnow` for multi-platform data, so an upstream API change can affect TrendRadar without a repository change. The README does not say whether TrendRadar includes a fallback provider, caches responses, or guarantees delivery when a platform is blocked. Users who need complete historical coverage should not treat the hot-list output as an archival record.

Notification size is another boundary. The release notes explicitly discuss the case where `frequency_words.txt` is empty and every news item is pushed. The README warns that this is limited by message size and suggests either using GitHub Pages or reducing the number of platforms. That makes TrendRadar less suitable for a phone-only setup that must receive every collected item.

The project is also a fork-oriented application rather than a packaged service with a documented migration API. A major version change may require recreating the fork. There are no GitHub releases, so operators cannot rely on a release-page upgrade stream. The README also does not document rollback. These constraints increase maintenance effort compared with a conventional container image that has documented upgrade and rollback procedures.

Finally, the project is oriented toward Chinese platforms and Chinese messaging services. The README does not establish support for arbitrary international sources, custom data providers, or a general-purpose news ingestion API. Those needs require checking `config/`, `main.py`, and the `api/` directory before adoption.

TrendRadar compared with a direct newsnow integration

The closest documented alternative is to call `newsnow` directly and build only the notification or reporting layer that the organization actually needs. That approach avoids TrendRadar's keyword grouping, repeated-appearance counting, scheduling choices, and multi-channel formatting, but it also removes its configuration model and documented deployment paths.

A direct integration can be simpler when an engineering team already owns a scheduler, database, and notification service. It gives the team more control over storage, retries, provider selection, and API contracts. TrendRadar is more practical when the goal is a quick GitHub Pages or GitHub Actions deployment, with keyword filtering and notifications configured through the project rather than developed in house.

The trade-off is control. TrendRadar adds a processing and distribution layer around an external API, but it does not document all of the guarantees an integration team may need. A direct `newsnow` integration is the better choice for custom data ownership and long-term backend control. TrendRadar is the better choice for a lightweight monitoring workflow where the documented channels and fork workflow are sufficient.

License, maintenance, and operating costs

The repository is licensed under `GPL-3.0`. That license identifies the project's licensing model, but choosing it for a deployment still requires reviewing the actual `LICENSE` file and considering how modified or hosted versions will be distributed. This article does not provide legal advice about GPL obligations.

The repository is not archived. Its last push was on 2026-08-19. However, it has no GitHub releases, and the README's update instructions rely on replacing `main.py` and handling major upgrades by recreating the fork. That is an upgrade cost even when recent commits are available.

The fixed Python dependencies in `requirements.txt` include `requests==2.32.4`, `pytz==2025.2`, `PyYAML==6.0.2`, and `playwright~=1.45.0`. The README also mentions Docker and GitHub Actions, but it does not give a complete operational runbook. Before adopting the project, an operator should inspect `.github/`, `docker/`, `config/`, and the behavior of the `newsnow` endpoint. A repository with recent commits can still impose maintenance work when releases, migrations, rollback instructions, and external API behavior are not documented.

Editorial conclusion

TrendRadar is a practical choice for a small team or an individual who needs scheduled monitoring of Chinese platform hot lists and already accepts GitHub-based deployment. It is less suitable for users who need a fully independent data pipeline, guaranteed platform coverage, or a mature release process. Verify the configured platforms, upstream `newsnow` availability, notification credentials, storage behavior, and upgrade path before adopting it.

Frequently asked questions

Official sources

1. Issues
2. joyce677/TrendRadar on GitHub
3. License: GPL-3.0
4. Project website
5. README