# light-chaser puts a React designer and a Spring Boot service in one repository > light-chaser is an open source data visualisation platform for large screen displays and reports, with the drag-and-drop designer and the backend service merged into a single codebase. Startup is two commands and SQLite is the default store, but the product split, the release numbering and the licence wording all leave questions a team has to answer for itself. **xiaopujun/light-chaser** — light chaser is a lightweight data visualization designer tool - Repository: https://github.com/xiaopujun/light-chaser - Website: http://www.lcdesigner.cn:3000/home/projects - Stars: 872 · Forks: 127 - Language: TypeScript - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/xiaopujun-light-chaser ## One repository, two applications, one SQLite file The defining decision in light-chaser is that the front-end designer and the back-end service live in the same codebase. The repository root holds four directories and two generated paths: frontend/, backend/, docs/, scripts/, plus lc-server.db, the SQLite database file created after startup, and logs/, the directory for service logs. The documentation says this arrangement exists so development, joint debugging, building and deployment are handled together rather than across separate repositories. The stack is spelled out in the README. The front end is React 18, Vite 5, TypeScript 5 and MobX. The back end is Java 17, Spring Boot 3.2.5 and MyBatis Plus 3.5.5. The database is SQLite as the default primary store. Deployment is Nginx, Docker and Docker Compose. That combination makes the platform a self-contained application rather than a set of services. A designer page, a data source registry, image storage and a chat-style model endpoint all live behind one process. The trade-off is that the two halves have different toolchains, so a developer touching the designer still needs Node.js and pnpm on a machine that is also running Maven and a JDK. ## mvn spring-boot:run and pnpm dev are the entire startup path The environment requirements are Node.js, pnpm, Java 17 or newer and Maven 3.6 or newer, and the README recommends starting the back end before the front end. ```bash cd backend mvn spring-boot:run ``` The service listens on http://localhost:8080, and the SQLite database uses jdbc:sqlite:${user.dir}/lc-server.db, so the file appears in the directory the command was run from. ```bash cd frontend pnpm install pnpm dev ``` The designer is served at http://localhost:5173, and in development mode requests to /api and /static are proxied to http://127.0.0.1:8080, which is why the back end has to be up first. The front end also ships the usual script set for building and checking the project. ```bash pnpm build pnpm lint pnpm preview pnpm check ``` The back end side has its own three, which cover a clean compile, the test run and the packaged artefact. ```bash mvn clean compile mvn test mvn clean package ``` ## The database file lands in the directory you launched from The default data source is defined as jdbc:sqlite:${user.dir}/lc-server.db, which means the SQLite file is created in the working directory of the process that starts the service. The documentation says the database file is generated in the current startup directory. That detail is the first thing to know when you run the back end from different places. A second setting follows the same idea. light-chaser.project-resource-path defaults to the startup directory when it is not configured, and the README advises pointing it at a directory that is persistent and writable. Project resources, images and covers are stored under that path, with images mapped to /static/images and covers to /static/covers. So the service has two pieces of state, the database file and the resource tree, and by default both are relative to wherever you happened to launch the process. On a developer laptop that is convenient, since deleting the directory resets everything. In a container or on a server it is a configuration decision, because a working directory that is ephemeral will lose projects and uploaded images on the next restart. ## The designer talks to the service through a dev proxy The two halves are wired together by an /api and /static proxy. The proxy configuration lives in frontend/vite.dev.config.ts, and for production the README points at frontend/nginx.conf and frontend/Dockerfile, where the build output is served by an Nginx image. The back-end surface is a small set of REST modules, listed in the README. /api/project handles creation, update, copy, import, export and detail. /api/commonDatabase handles data source management and connection tests. /api/aiModel covers model management and invocation. /api/image covers upload, paging and deletion. /api/db/executor runs SQL, /api/crypto exposes encryption capabilities and /api/debug is the debugging endpoint. The presence of a SQL executor and a crypto endpoint in the same service is worth flagging for anyone putting this behind a network. The README does not describe authentication or authorisation for these routes, and the back end defaults to binding on localhost during development. ## AI features are gated by a config flag and three environment variables The platform includes AI model management, style optimisation and data optimisation. The back end exposes an AI model proxy endpoint so the front end can call an OpenAI-compatible model service, and a single setting, light-chaser.ai.enabled, controls whether those features are active at all. The model list is configured through light-chaser.ai.models, and the documentation says the defaults can be overridden through the environment variables LC_AI_MODEL, LC_AI_BASE_URL and LC_AI_API_KEY. The naming is straightforward: a model identifier, a base URL and a key. The scope of the data optimisation feature is narrower than the name suggests. The README states that data optimisation only supports the data source types the open source edition already has, which are static, api and database. A user planning to point the feature at a file or a spreadsheet endpoint will not get it, and the feature list in the README also mentions a code editor and complex configuration support in the designer, plus a template market and preview and result pages that make up the delivery path from project to exported page. ## RSA keys appear on first startup, and the deployment script bundles everything Encryption settings follow the same path-derived pattern. light-chaser.crypto.rsa.public-key-path and light-chaser.crypto.rsa.private-key-path default to locations under light-chaser.project-resource-path/keys/, and the documentation states that if those files do not exist, they are generated and persisted at startup. RSA and AES configuration is described as built in under light-chaser.crypto. The practical consequence is that the first run writes key files to disk, so the resource path has to be writable and the keys have to be backed up with the rest of the project data. Delivery is handled by one script. ```bash node scripts/deploy-same-origin.js ``` It builds the front end, merges frontend/dist into backend/src/main/resources/static, repackages the back end and additionally produces backend/target/lc-server-release.zip. That archive contains lc-server.jar together with the deployment and operations document, which makes it the artefact to hand to whoever runs the system. The script has two conveniences for cautious use. Passing --dry-run previews the steps without executing them, and if the default Java on the machine is older than 17, --java-home /path/to/jdk17 points the back-end build at a specific JDK. Split deployment is still possible: pnpm build for the front end with frontend/Dockerfile or the Nginx configuration, and mvn clean package for the back end, which produces backend/target/lc-server.jar. ## Two versions, one licence statement and a demo account in public The version story in this repository is confusing enough to state plainly. The README badge reads v2.0.0, while the listed releases are 1.4.0 from 2024-08-10, 1.3.0 from 2024-06-29 and v1.2.0 from 2024-05-30. The last push was on 2026-04-25. A team pinning versions has to decide which of those numbers corresponds to the code it actually wants, and the documentation does not reconcile them. The licence wording has a similar tension. The README says the project follows the Apache 2.0 licence and asks that the work be attributed, and then adds that the project is for learning and exchange and that commercial use requires obtaining authorisation first. Apache 2.0 grants broad commercial rights, so the extra sentence narrows what the licence alone would allow, and the README does not say how the authorisation is obtained. On top of that sit two paid editions described in the README, a private deployment edition aimed at team collaboration, permission management and business delivery, and a desktop edition for offline demonstration and single machine delivery. Both are linked from lcdesigner.cn, and that site is reachable with the account admin and the password 123456, printed in the README so anyone can try the hosted version. Whatever you conclude about the open source code, those credentials being public is a fact about the hosted product rather than about the repository. ## Conclusion light-chaser fits a team that wants to build large-screen dashboards and report pages in one place, with a designer, a data source manager, a SQL executor and a one-command delivery path, and that is comfortable running a Spring Boot service alongside a Node build. It does not fit a team that needs a clear licensing answer for commercial deployment or a predictable release stream, since the README asks commercial users to obtain authorisation and the listed releases stop at 1.4.0 while the badge shows v2.0.0. Verify first the licence terms for your use, then run the backend and frontend locally and confirm the SQLite file and resource path are written where you intend, by setting light-chaser.project-resource-path before the first start. ## FAQ ### How do I start light-chaser locally? Start the back end first with cd backend and mvn spring-boot:run, which listens on http://localhost:8080, then start the front end with cd frontend, pnpm install and pnpm dev, which serves http://localhost:5173. The front end needs the back end running because /api and /static requests are proxied to it in development. ### Where does light-chaser store its data and uploaded files? The default data source is jdbc:sqlite:${user.dir}/lc-server.db, so the SQLite file is created in the directory the service is started from. Project resources, images and covers follow light-chaser.project-resource-path, which also defaults to the startup directory, and the README advises pointing it at a persistent writable directory. ### How do I enable the AI features in light-chaser? Set light-chaser.ai.enabled, configure the model list in light-chaser.ai.models, and override the defaults with the LC_AI_MODEL, LC_AI_BASE_URL and LC_AI_API_KEY environment variables. Data optimisation only supports the static, api and database data source types in the open source edition. ### What does the deployment script produce? Running node scripts/deploy-same-origin.js builds the front end, merges frontend/dist into backend/src/main/resources/static, repackages the back end and writes backend/target/lc-server-release.zip containing lc-server.jar and the deployment and operations document. Add --dry-run to preview the steps. ### What licence does light-chaser use? The README states that the project follows the Apache 2.0 licence and asks that attribution be kept, but it also says the project is for learning and exchange and that commercial use requires obtaining authorisation. The repository's own licence field is not filled in. ## Sources - [Issues](https://github.com/xiaopujun/light-chaser/issues) - [Project website](http://www.lcdesigner.cn:3000/home/projects) - [README](https://github.com/xiaopujun/light-chaser/blob/master/README.md) - [Releases](https://github.com/xiaopujun/light-chaser/releases) - [xiaopujun/light-chaser on GitHub](https://github.com/xiaopujun/light-chaser) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xiaopujun-light-chaser