# novel: a Spring Boot 3 and Vue 3 reading platform built as a teaching project

> A four repository Chinese novel platform with a paid tutorial attached, where the interesting part is the stack list and the sharding decision.

**201206030/novel** — novel is a learning-oriented novel platform built with Spring Boot 3 and Vue 3 as a decoupled frontend/backend project, with step-by-step tutorials for building and launching a production-grade Java system from scratch. It consists of a reader portal, a writer admin backend and a platform admin backend, with features including recommendations, search, rankings, reading, comments, a membership center, a writer zone, paid subscriptions and news publishing.

- Repository: https://github.com/201206030/novel
- Website: https://novel.xxyopen.com
- Stars: 5,829 · Forks: 1,454
- Language: Java
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/201206030-novel

## One product spread across four repositories

The project description sets expectations clearly: this is a full stack novel platform, built as a learning exercise, with a tutorial that walks from an empty directory to something deployed. The feature list is long and specific enough to be useful as a scope statement. Reading, recommendations, search, leaderboards, comments, a membership centre, a writer area, paid subscriptions and news publishing are all named, and they are split across a novel portal system, a writer backend and a platform admin backend.

What is more interesting than the feature list is the repository layout, which is four separate projects. The backend is at 201206030/novel, with mirrors on Gitee and GitCode. The Vue frontend is a different repository, novel-front-web. Then there is novel-plus, described as the online application version, and novel-cloud, the microservice version. Same mirrors on each.

So the platform is not one codebase with optional modules, it is a product line at three levels of operational ambition, and the tutorial picks one. The README marks both the backend and the frontend repositories as still being updated, which is a more honest signal than a version badge. The tree of the backend is small and conventional by contrast: `pom.xml`, `mvnw`, `mvnw.cmd`, `.mvn/`, `src/`, `doc/`, and `LICENSE`. The Maven wrapper is checked in, which is the first practical detail that matters when you clone it.

## The environment list, and why three of the five services are optional

The stated development environment is MySQL 8.0, Redis 7.0, JDK 21, Maven 3.8 and Node 16.14, with IntelliJ IDEA marked optional. Three more services are listed but marked optional: Elasticsearch 8.2.0, RabbitMQ 3.10.2 and XXL-JOB 2.3.1.

The note under the list explains the mechanism rather than just the outcome. Each of those three can be switched on through a matching `enable` property in `application.yml`, and all three are off by default. That is the single most useful line in the README for anyone about to clone this, because it turns a six service system into a two service one. MySQL and Redis are the floor; everything else is opt in.

The versions are worth reading as a set rather than individually. JDK 21 with Spring Boot 3.3.0 is a deliberate pairing rather than a coincidence, and the release notes for v3.5.0 list the upgrade to Java 21 as a dependency change, meaning the project moved onto it deliberately rather than drifting. Node 16.14 on the frontend side is older than you would pick today, and it is a number to notice before you start building a frontend toolchain around it.

## Reading the backend stack table for what the project actually uses

The technology table is the most information dense part of the README, and it is worth reading closely because several entries explain an architectural choice rather than naming a library.

MyBatis at 3.5.9 with MyBatis-Plus at 3.5.3 on top of it is the persistence layer. ShardingSphere-JDBC at 5.5.1 is listed as the support for database sharding and table partitioning, which tells you the data model was designed with horizontal split in mind from the beginning. Redisson 3.17.4 provides the distributed lock and Redis 7.0 the distributed cache, while Caffeine 3.1.0 sits alongside as the local cache, so there is a two tier cache arrangement rather than a single one.

The observability and operations entries are just as telling. Sentinel 1.8.4 is there for traffic control, Springdoc-openapi 2.0.0 generates Swagger 3 documentation from the code, and Spring Boot Admin 3.0.0-M1 handles application management and monitoring. Sentinel, an Alibaba component, is not a default choice in a Spring project, so its presence says the author expects real traffic shapes rather than a demo. One detail worth flagging: several of these versions are pre-release milestones, Spring AI at 1.0.0-M6 and Spring Boot Admin at 3.0.0-M1 in particular. A reader copying this stack into production would be adopting milestone builds that the author chose for teaching convenience.

## What v3.5.0 changed, and what it says about the direction

There are three tagged releases in the repository. v3.5.0 came on 2025-02-20, v3.4.1 on 2024-06-02, and v3.4.0 on 2023-04-25. Only v3.5.0 carries change notes in the release body itself; the two earlier ones point to a changelog on docs.xxyopen.com.

The v3.5.0 notes are more interesting than a version number usually is, because they show a project being modernised rather than extended. Java moves to 21, Spring Boot to 3.3.0, ShardingSphere-JDBC to 5.5.1. Two dependencies are added outright: Spring AI for AI assisted writing, and Flyway for database version management. Two more are added for operations: Logbook for logging HTTP requests and responses, and a switch from Undertow back to Tomcat as the embedded container, which is a move toward the Spring Boot default.

The optimisations are equally concrete: virtual threads are enabled, and the `/env` endpoint is configured to show property values only in the dev environment. That last one is a security fix stated plainly, the kind of thing that appears in a release when the author has had a report. Putting AI writing into a platform that already has a writer area and paid subscriptions is the most quotable decision here, and it is the one most likely to be revised.

## Where the repository ends and the documentation begins

The README is an index, not a manual, and it is built around a link to the tutorial at docs.xxyopen.com/course/novel described as step by step from zero. Release notes live at docs.xxyopen.com/log/novel.html. The homepage novel.xxyopen.com is the deployed application.

So the repository's job is to be the thing the tutorial diffs against, and its `doc/` directory is presumably part of that. Everything a reader actually needs to make the system run, from application.yml keys to the optional service toggles to how the sharding is configured, is on the other side of that link. That is a reasonable division for a teaching project, where the prose is the product, but it means evaluating the code quality means reading both.

There is a second reason to treat the docs as load bearing. Because the tutorial builds up the system in stages, the code at any commit is the code for one stage. If you are comparing this against your own application, the interesting questions are which stage a given commit corresponds to and whether the later stages are still in this repository, and the release tags are the only anchors the README gives you for answering that.

## Conclusion

novel earns its place as a reference implementation rather than as software you would deploy unchanged. The stack table is precise about versions down to Tomcat 10.1.24 and Redisson 3.17.4, the three optional services are off by default so a first run needs only MySQL and Redis, and ShardingSphere is wired in from the start rather than bolted on later. What the repository does not settle is the one thing a reader most wants: the backend and the Vue frontend are separate repositories, and the backend one is marked as still being updated, so the pair you clone today is not a frozen matching set. If you want to follow the tutorial at docs.xxyopen.com the four repository split is exactly why it works, since each stage maps to a repository you can diff against your own.

## FAQ

### What do I need installed before I can run the novel backend?

MySQL 8.0, Redis 7.0, JDK 21, Maven 3.8 and Node 16.14. Elasticsearch 8.2.0, RabbitMQ 3.10.2 and XXL-JOB 2.3.1 are listed as optional and are switched on through matching enable properties in application.yml, so a first run needs only the database and the cache.

### Is the frontend in the same repository as the backend?

No. The Vue frontend lives in novel-front-web, the online application version in novel-plus and the microservice version in novel-cloud, each mirrored on Gitee and GitCode. The README marks both the backend and frontend repositories as still being updated.

### Does the project support splitting the database across shards?

ShardingSphere-JDBC at 5.5.1 is in the stack specifically for database sharding and table partitioning, and the v3.5.0 release notes record an upgrade to that version. The configuration detail itself is not in the README.

### What changed in the latest tagged release?

v3.5.0, published 2025-02-20, moved to Java 21, Spring Boot 3.3.0 and ShardingSphere-JDBC 5.5.1, added Spring AI for AI assisted writing, Flyway for database version management and Logbook for HTTP logging, switched back to the default Tomcat container, and enabled virtual threads.

## Sources

- [201206030/novel on GitHub](https://github.com/201206030/novel)
- [License: Apache-2.0](https://github.com/201206030/novel/blob/master/LICENSE)
- [Project website](https://novel.xxyopen.com)
- [README](https://github.com/201206030/novel/blob/master/README.md)
- [Releases](https://github.com/201206030/novel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/201206030-novel