# springboot-demo: a catalogue of Spring Boot quick starts, one directory each > Harries' springboot-demo is not an application but a shelf of small Spring Boot projects, the README claims 170 usage scenarios, and each one lives in its own top level directory with a pom and a source tree. Redis, Kafka, MySQL, Elasticsearch, MinIO, Nacos, XXL-Job, Flyway, Neo4j, Flink and GraalVM JavaScript are all there, with the environment built in Docker and a pair of documentation links per module. **Harries/springboot-demo** — a simple springboot demo with some components for example: redis,solr,rockmq and so on. - Repository: https://github.com/Harries/springboot-demo - Website: https://www.harries.blog/type/2459.html - Stars: 576 · Forks: 275 - Language: Java - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/harries-springboot-demo ## A shelf of samples, not a system The repository description is a simple springboot demo with some components for example: redis, solr, rockmq and so on, and the README expands it into the claim that it contains 170 usage scenarios, with the code ready to use and the environment built entirely with Docker, so a sample can be deployed quickly. The framing matters. This is not an application with modules, and it is not a library. It is a large set of small independent Spring Boot projects, each in its own top level directory, each demonstrating one integration. The first row of the module table makes the point: a demo module described as a Springboot minimalist demo, which is the starting point everything else is built on top of. The stated goals are Quick Start, Easier Understand and Simple Use, and each module is paired with documentation in two languages. Every row of the table carries a link to a Chinese post on harries.blog and an English post on a Medium publication, so a module is never just code, it comes with a walkthrough. For the audience this is straightforward. A Spring Boot developer who has read the documentation for a component and still wants to see a working integration, or who needs a project skeleton to copy into a new service, gets it here. The repository carries a LICENSE file with the MIT licence, and the homepage links to a post on the author's blog. The scale is the point, and it is also the warning. A directory per integration, and hundreds of them, is a very different maintenance proposition from a library with one public API. ## The module list starts with the components everyone needs The first twenty-six rows of the module table are the integrations a Spring Boot developer is most likely to reach for, and the first part of the list reads like a shopping list of the Java ecosystem. ```bash demo redis hanlp mysql minio elasticsearch rocketmq graylog mongodb prometheus kafka nacos xxl-job email logback docker ``` After those come the rest of the table: flyway for schema migrations, webSocket for real time connections, neo4j for a knowledge graph, flink for stream processing, graalvm-js and python for running other language engines inside a Spring Boot process, hazelcast for distributed caching, mapstruct for bean mapping, jpa and mybatis-plus for persistence. Two of these deserve a note because the description is not a plain integration. The neo4j row is described as integrating neo4j to realize a simple knowledge graph, which is a bigger claim than a client stub. The graalvm-js and python rows are about running a scripting engine inside the JVM rather than about a service, which is the kind of thing a Spring Boot application rarely needs and therefore rarely has a good example of. The pattern in the table is that each module is a quick start demo, and each links to its own write up. The value for a reader is that the write up and the code are in the same place, which is the whole appeal of a sample repository. ## The top level directory is a second, longer feature list The repository root is where the scale becomes visible, because the module table in the README covers only part of what is there. The top level entries include directories such as ANTLR, Alipay-facetoface, Aviator, Blockchain, BloomFilter, Captcha, Chronicle-Queue, ContentNegotiation, Deeplearning4j, Exception, GeoTools, GraphQL, InterfaceSecurity, JMH, JSON-Schema-Validator, JSch, Kubernetes, Liquibase, Lombok, MFA, Milvus, Mockito, MultiProfiles, Puppeteer, Quarkus, Qwen, RedisSearch, RedisVectorStore, Screw, Selenium, SoftwareLicense, SonarQube, SpEL, Spring-Shell, Spring-Task-Scheduler, SpringBatch, SpringMobile, SpringRetry, Statemachine, Tensorflow, Tess4j, Timefold Solver, Twilio, Undertow, WebRTC, accessDB, activiti, ai, akka, annotations, antihotlinking, api-version, aspect, async, atomikos and atomix, and the listing continues well past that into the rest of the alphabet. So the README table is a curated subset, and the directory tree is the full catalogue. A few of the names tell you what kind of sample you will find. Kubernetes and Docker are deployment oriented. JMH is benchmarking. Quarkus is the alternative framework rather than a Spring integration. Milvus, Tensorflow, Deeplearning4j, RedisVectorStore and Qwen are the machine learning and vector search corner. Twilio, Activiti, Statemachine, Tess4j and WebRTC are product or domain specific. Mockito, Lombok, JSch, MapStruct and JMH are developer tooling. And the lowercase names such as accessDB, annotations, antihotlinking, api-version, aspect and async are general Spring Boot techniques rather than third party integrations. That mixture tells you the collection is broader than the table suggests, and it also tells you it is a working notebook of one developer rather than a curated set of production patterns. ## The demo module is the thing to read first Only one module appears in the example files listing, demo/, with a pom.xml and a src/ directory, and that is not an accident. The module table describes it as a Springboot minimalist demo, and it is listed first. The most useful way to read this repository is as a sequence rather than a catalogue. Start with the minimalist demo to see the shape of a project in this collection, then move to whichever integration you actually need, because each module is small enough to read in one sitting and self-contained enough to copy without the rest of the tree. The example files listing shows demo/pom.xml and demo/src/, and that pairing is the whole pattern: a pom and a source tree, with the pom carrying the dependency and the configuration for one integration. The README does not document the Spring Boot version each module targets, the Java version, or how the modules are meant to be run, and the example files listing does not include the Docker compose files that the environment claim implies, so the visible files do not show how the infrastructure is started. What the visible files do show is a consistent documentation pattern. Every module has a Chinese article on harries.blog, at an archive URL with a numeric identifier, and an English article on a Medium publication under a different author name. The homepage is a post on the same blog, at a type URL, and the README is a short overview in English that points outward rather than inward. That is a deliberate choice. The repository is a pointer to a body of writing, and the writing is where the teaching actually happens. ## Docker is the environment, and one module is about Docker itself The README states that the environment is all built with Docker, and the module table includes a docker entry described as a Spring Boot integrated docker quick start demo. Those two facts are related in a way that is easy to miss: the environment for running the samples is built with Docker, and there is also a sample about how to put a Spring Boot application into a container. The other entries in the table have a similar property. Some are infrastructure that has to exist for a sample to run, and some are about a library. Redis, Kafka, MySQL, MinIO, Elasticsearch, MongoDB, RocketMQ, Nacos and XXL-Job are all things you would start with Docker. Prometheus, Graylog and Flyway are tooling that a real deployment includes. Docker, Kubernetes, Liquibase and SonarQube are the operational layer. And WebSocket, Neo4j, Flink, Hazelcast, Thread scheduling, batch, retry, content negotiation, interface security, multi profile, API versioning and aspect programming are the Spring Boot features that make a demo worth reading. The two blended categories are the ones that need judgement. The faq entry about a captcha, the one about a bloom filter, the one about blockchain, and the one about a state machine are libraries or patterns, not integrations, so they sit somewhere between a tutorial and a code sample. And the entries with names like SoftwareLicense and InterfaceSecurity are the kind of thing that only makes sense as a demonstration of a technique rather than as something to deploy. ## A single release tag, and a repository that moves The maintenance picture is worth stating plainly, because a repository of 170 samples and no version numbers is a different kind of artefact from a library. The only visible release is release-v1.0, dated 2024-01-30. The last push to the repository was on 2026-05-10. There are no GitHub release notes, no changelog, and no statement in the README about which Spring Boot version the samples target. That combination tells you the shape of the project. It is a personal collection that the author keeps adding to, and the samples are snapshots of a moment. A module written against one version of Spring Boot will not automatically build against the next, and with 170 of them there is no practical way for anyone to keep them all current. The same applies to the middlewares: a Redis or Elasticsearch client library moves, and a sample that pins an old version will start failing to resolve dependencies or change behaviour. The honest use of this repository is therefore as a source of working code to read and to copy, not as a set of maintained components. If you take a module into your own project, you are taking on the update: the dependency versions, the configuration properties that Spring Boot has renamed, and the API changes in the client library. The value is in the shape of the integration and the accompanying article, not in the freshness of the code. The alternative approach is to read the documentation for the component you need and write the integration yourself against the current version. That costs more time and gives you code you can defend. Copying a sample gives you a working baseline in minutes and a diff to review later. Which one is right depends on how much of the code you intend to keep. ## Conclusion springboot-demo suits a Spring Boot developer who wants a working starting point for an integration rather than a paragraph of documentation, and it suits a team that learns by copying a small, readable project. It does not suit a production codebase, because these are teaching samples with no stated compatibility matrix, no release process beyond a single tag, and no promise that they track the current Spring Boot release, and it does not suit you if you need a supported library rather than an example. Check three things before you copy anything from it: which Spring Boot version the module you want actually targets, because the README does not state it, whether the module you need is one of the 170 or one of the directories listed further down the repository, and how old the surrounding code is, since the last push to the repository was on 2026-05-10 and the only release tag is release-v1.0 from 2024-01-30. The most sensible use is as a starting point you then update, not as a dependency you then trust. ## FAQ ### What is Harries' springboot-demo? It is a collection of small, independent Spring Boot projects, one per top level directory, which the README describes as 170 usage scenarios with the code ready to use and the environment built with Docker. It is MIT licensed and is a set of teaching samples rather than an application or a library. ### Which integrations are covered by springboot-demo? The README table lists demo, redis, hanlp, mysql, minio, elasticsearch, rocketmq, graylog, mongodb, prometheus, kafka, nacos, xxl-job, email, logback, docker, flyway, webSocket, neo4j, flink, graalvm-js, python, hazelcast, mapstruct, jpa and mybatis-plus, and the top level directory tree holds many more, including machine learning, vector search and framework alternatives. ### How is each module in springboot-demo documented? Each row of the module table links to a Chinese article on harries.blog and an English article on a Medium publication, and the README points to a homepage post on the blog as the entry point for the collection. ### Is springboot-demo suitable for production use? It should be read as a reference and copied selectively rather than depended on. There is a single release tag, release-v1.0 from 2024-01-30, no changelog, and the README does not state which Spring Boot version the samples target, so any code you take has to be updated to the versions you actually run. ### Where do I start with springboot-demo? With the demo module, described in the table as the Springboot minimalist demo, and the example files listing shows demo/pom.xml and demo/src/. From there, move to the one integration you need, since each module is self-contained. ## Sources - [Harries/springboot-demo on GitHub](https://github.com/Harries/springboot-demo) - [License: MIT](https://github.com/Harries/springboot-demo/blob/master/LICENSE) - [Project website](https://www.harries.blog/type/2459.html) - [README](https://github.com/Harries/springboot-demo/blob/master/README.md) - [Releases](https://github.com/Harries/springboot-demo/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/harries-springboot-demo