diyhi/bbs and the Chinese community platform built on Spring Boot 4

A forum and a Q&A engine in one application

巡云轻论坛, usually rendered as a lightweight forum, is a community system built on JDK 21 and Spring Boot 4.x with a separated front end and back end architecture, adapting to both mobile and desktop. The project integrates a forum module and a Q&A module, and the repository description also mentions a sharding strategy for frequently accessed tables to work around single table performance bottlenecks, plus adaptation to the Dameng database used in domestic Chinese environments and to MySQL.

The stack is stated plainly in the technology selection section: Spring Boot 4.x with JPA, Ehcache and Lucene. The supported platform is JDK 21 and above with MySQL 5.7 and above.

The forum and Q&A combination is the thing that distinguishes it from a plain bulletin board. A topic supports posting, editing, commenting, replying, moderation of all three, search, favourites, likes, video uploads, and visibility rules that can be driven by a password, a member level, points or cash, along with role-scoped tags and a red packet feature. The Q&A module adds asking and appending to questions, answers, replies, moderation, search, cash and points bounties, favourites and marking a best answer.

The audience is a Chinese language community operator who wants a monetised community, and a Java team that would rather extend a system than build one. The list of administrative modules in the README is the clearest evidence of the second group, since it includes employee and role management, member card management with orders, third party login interfaces, online payment interfaces, SMS interfaces, sensitive word filtering, database backup and restore, server node parameters, and an upgrade function.

Sharding hot tables, and what that buys

The sharding strategy is the one piece of architecture in the description that is worth thinking about before you deploy, because it changes how you operate the database.

The claim is that frequently accessed tables are split across shards to remove the single table bottleneck. In a forum, the tables that grow fastest and get read most are the obvious ones, the post content, the topic list, the counters for views and likes, and the activity feed. A system that has run for a year with an active community can have a topic table in the millions of rows, and every list page becomes a full table scan unless something is done about it.

Splitting the table is a straightforward answer to that problem, and it is a common one in Chinese Java projects where the alternative, a read replica or a search index, is more work to operate. The cost is that the application layer now has to know which shard a row lives in, which means the sharding key becomes a schema decision that is hard to change later, and any query that does not carry the key has to fan out across shards.

The Lucene dependency fits here. A search index over the content handles the full text queries that a sharded relational table handles badly, and the README lists search for both topics and questions as a feature. So the system uses sharding for the write and list paths and Lucene for the read and search path, with Ehcache sitting in front for repeated queries. That is a sensible arrangement for the workload, and it also means three moving parts in the data path rather than one.

JPA, Ehcache and Lucene in the same request path

Four technologies are named in the technology selection, and their combination says more about the design than a list of features would.

JPA is the persistence layer, which gives the project the benefit of an object model over the database and the cost of a persistence layer that sits between the business logic and the sharding strategy. When a table is sharded, a JPA layer can hide the distribution or can make it explicit, and the difference shows up in how you write a query that touches several shards.

Ehcache is the in-process cache, and in a Spring Boot application it is a common choice because it needs no separate server. Its role here is the hot read path, the topic list, the counters, the site settings that every page reads. That is a sensible place to spend memory on a Raspberry Pi sized server, if that is the target.

Lucene is the search engine, and it runs embedded rather than as a service, which keeps the deployment to a single JVM. The consequence is that the index lives in the application, which is fine on one node and awkward when you scale out, since two instances with separate indexes will drift unless one owns the index.

That last point is the limitation to keep in mind. The project is designed for a single node deployment, and the server node parameters in the site settings suggest that a node concept exists for larger installations, but the documentation does not describe how the index, the cache and the shards behave across nodes. If your plan is a multi node deployment, that is a question to ask before you commit.

Running it from source in five steps, including a default password

The source run tutorial is written for IntelliJ IDEA and describes a manual setup rather than a deployment. Import the source into the IDE as a Maven project, change the database settings in the configuration file, refresh the Maven panel to reload dependencies, run a specific method, and then start the application.

The two files that matter are named in the instructions:

src\main\resources\application.yml
src\test\java\cms\Init.java

The first holds the database information you have to replace with your own. The second is the interesting one: the tutorial says to open Init.java, select the install() method and run it, and that this operation creates the external folders and imports the SQL into the database. So schema creation and seed data happen through a test class rather than a migration tool, which is a decision with consequences. There is no Flyway or Liquibase step described here, and the upgrade function in the site settings suggests the project handles version upgrades through the application itself instead.

After that, the backend runs on port 8080 and the front end is pointed at it through the .env.development and .env.production files, while the admin console is reached on port 3000 under /admin/login. The administrator account starts as admin with the password 1234567, and the README notes that you can change it yourself. That default is the one thing in this tutorial you should not skip, because a forum that reaches the internet with a known admin password is a support queue waiting to happen.

The repository ships a Maven wrapper, mvnw and mvnw.cmd, so a build does not need a system Maven install.

The two front ends are separate projects on Gitee

The most important structural fact about this repository is what it does not contain. The README sends the desktop front end to one repository, bbs-web-pc-jdk21, and the administration back office to another, bbs-web-admin-jdk21, both hosted on Gitee rather than GitHub. The topics list the project as using Vue3, which matches a JavaScript front end split from the Java back end.

That means this repository is the API and business logic only. A team evaluating it has to assemble three repositories, not one, and has to be aware that the two front ends may not be released in step with the back end. The version naming in the repository links carries a jdk21 suffix, which suggests the front end repositories are versioned per runtime, another thing to track.

For an evaluator, this is a real cost. There is no single clone that gives you a working system, and no easy way to see the whole product in one place. The demo site is the way to see the result, and the README points at a page on the official site where the front and back office demo addresses, login accounts and passwords are published.

The repository layout reflects the split. There is a pom.xml at the root, an mvnw wrapper, a src/ directory for the Java code, a lib/ directory, and an image/ directory holding the screenshots that the README embeds.

Payments, points and revenue splits are first class features

The feature list is long, and the parts worth drawing attention to are the ones that make this a commercial community platform rather than a hobby forum.

There is a platform revenue module covering revenue shares for unlocking hidden topic content and for Q&A bounties, which means the system tracks money owed to content authors. There is online payment management for payment interfaces, membership card management with member card lists and member card orders, and a membership module with levels, registration items, roles, private messages, system notifications, favourites, follows and fans, plus WeChat login. Within topics themselves, visibility can be gated by a password, a member level, points or cash, and there is a red packet feature and a cash and points bounty system in the Q&A module.

This is a coherent model: the same currency system runs through paid topic visibility, bounties, membership cards and revenue sharing. It is also a model with real legal and operational weight, since it handles money movement, platform commission and third party payment interfaces, and that weight is not visible in the feature list but should be visible in an evaluation.

The remaining modules are the ordinary furniture of a Chinese community backend: staff and role management with login logs, front end module management with API lists and site columns, online help categories, view count management, friendly links, guestbook messages, file packaging, system notifications, sensitive words, database backup and restore, server node parameters, upgrades, SMS interfaces with error logs, third party login interfaces and thumbnail management.

AGPL-3.0 and a README that bans commercial use

The licence metadata for the project declares AGPL-3.0, and the LICENSE file sits at the root of the repository. The README, under a section titled usage restrictions, states that this lightweight forum project is prohibited from commercial use. Those two statements are in direct conflict, and a team that wants to use this for anything revenue generating has to resolve it before writing code.

The conflict matters more than it might appear. AGPL-3.0 is the strongest of the common copyleft licences, with a network clause that obliges you to offer the corresponding source to users who interact with the software over a network, which is exactly the case for a forum. If the additional restriction against commercial use holds, then the project is not AGPL-3.0 in its plain sense, because AGPL-3.0 itself permits commercial use and adding a restriction changes the terms you are distributing under. Whether the maintainer can grant AGPL-3.0 while also refusing commercial use, and what a user is actually licensed to do, is a legal question rather than a technical one, and the honest answer is that the documentation does not settle it.

On maintenance, the repository is not archived and the last push was on 2026-04-15. The recent releases are 7.0 on 2026-04-14, 6.9 on 2025-08-18 and 6.8 on 2025-05-28, so the numbering is a simple integer sequence with roughly three releases a year, and the newest one landed the day before the last push. The official site is diyhi.com, with a deployment guide at diyhi.com/article-15.html and a live demo at bbs3.diyhi.com.

Editorial conclusion

Adopt diyhi/bbs if you run a Chinese language community that needs more than a forum, specifically paid visibility, points, membership cards and a revenue split, and if you are comfortable running a Spring Boot application with Lucene and sharded tables. Do not adopt it for a commercial product until the licensing conflict is resolved, because the project metadata declares AGPL-3.0 while the README states the forum is prohibited from commercial use, and the two cannot both be honoured. Verify three things first: which front end repository you actually need, since the PC and admin front ends are separate projects on Gitee, that the database in your environment is one the build supports, and that the admin account ships with the default password 1234567 and you change it before the service is reachable. The last push was on 2026-04-15 and the newest release is 7.0 from 2026-04-14.

Frequently asked questions

Official sources

1. diyhi/bbs on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases