sekai-viewer: a web database for browsing Project Sekai data

A front end over somebody else's game data

sekai-viewer is a web database viewer for Project Sekai, and the word viewer matters. It is not a game, it is not a mod, and it does not own the data it displays. It is a browsing interface over a game's assets, characters, music and related records, and it exists because the game itself does not offer a good way to query that information.

The project is written in TypeScript with React, and the component library is Material UI, with the Material UI lab, the icons package and the data grid and date pickers extensions all present in the dependency list. The homepage is sekai.best, and the default branch is dev, with a version file, a changelog and a versionrc configuration suggesting releases are cut with a versioning tool.

The audience is a fan or a developer who wants to look things up: what a character has, how an event is structured, what a particular card is. For that audience the interesting decisions are in the interface and the data handling, not in the build.

There is one thing to say early, because it colours everything else. The README is the stock Create React App template. The project was bootstrapped with Create React App, and the documentation covers npm start, npm test, npm run build, npm run eject and the standard eject warning, with the learn more section pointing at Create React App and React documentation. Only two sections have been added to it: the i18next extraction script and the lint script. There is no architecture overview, no data source description and no deployment guide beyond the template text.

The repository listing tells you more than the README does. There is a vite.config.mts, so the build has moved to Vite, and a pnpm-workspace.yaml with pnpm-lock.yaml and a packageManager field pinning pnpm at 11.8.0. There is a Dockerfile and a Dockerfile.cloud, an nginx/ directory with a configuration, manifests/ for deployment descriptors, and .env, .env.development and .env.production for environment configuration.

The dependency list as a description of the app

The package.json dependencies describe the application better than the README does, and reading them is the fastest way to understand what the viewer does.

The game content is rendered with PixiJS and live 2D. There is @pixi/react for the React bindings, @esotericsoftware/spine-pixi for Spine skeletal animation, and @sekai-world/pixi-live2d-display-mulmotion, which is the Live2D display package for the game.

The database and graph side is where the viewer earns its name. There is @react-sigma/core with the forceatlas2 layout package, which is a graph renderer, and graphology for the graph data structure. That combination is what a relational browse interface and a relationship view are built on.

Media handling is unusually heavy for a web front end. @ffmpeg/ffmpeg and @ffmpeg/util put an ffmpeg pipeline in the browser, lamejs does MP3 encoding, browser-id3-writer writes ID3 tags, howler handles audio playback, and file-saver handles downloads. jszip is there for archive handling, and markdown-it with markdown-it-collapsible renders documentation text.

There are also two AI SDKs, the Anthropic SDK and the Google Generative AI SDK, plus @huggingface/transformers, which suggests in-browser model inference or an assistant feature somewhere in the product. The presence of @ctrl/react-adsense shows there is advertising in the app.

State and forms are handled with formik and formik-mui, with dayjs for dates, axios for requests, and cron for scheduling. The localisation stack is i18next with the browser language detector and the fetch backend, with react-i18next referenced in the README.

The practical takeaway is that this is a content-rich front end with client-side media processing, not a thin CRUD page.

Localisation, and the script that keeps it honest

The one part of the README that describes something specific to this project rather than to the template is the localisation setup, and it is worth reading carefully because the tooling described is unusual.

There is an npm run exti18n script, and it uses i18next-parser to extract the i18next JSON file from the code automatically, with a configuration file at i18next-parser.config.js. The generated JSON files are located in public/locales/{lang}/{namespace}.json. The README links to i18next and react-i18next for the underlying libraries.

The detail that makes this interesting is the direction of extraction. The translation files are not hand-written and committed as a chore; they are generated from the source code by a parser, and then the actual translations are filled in against that generated structure. The namespaces and the language directory layout are part of the contract, and the extraction step is what keeps the keys in sync with the code.

That matters for a viewer whose audience spans languages, and it is also a maintenance commitment: whenever a string changes in the source, the extraction has to be re-run and the changed key re-translated, and a project that skips that step accumulates stale keys that no longer map to anything on screen.

The README also mentions the app is a hybrid of these concerns with a couple of related tools, including a graph layout and a data grid, and the localisation layer is one of the few places where the maintainers have documented their own conventions rather than inherited them.

The build moved to Vite, and the container is a two-stage nginx image

Two things in the repository contradict the Create React App README, and both matter if you are picking this up.

The first is the build tool. The template documents npm run build as producing a build folder, and while the Dockerfile still copies from /app/build, the presence of vite.config.mts and the absence of react-scripts in the documented scripts suggests the application has been rebuilt on Vite while the README was left as it was. The packageManager field pins pnpm at 11.8.0 and there is a pnpm-workspace.yaml, so pnpm rather than npm is the intended workflow even though the README's commands are all npm.

The second is deployment. There are two Dockerfiles and an nginx/ directory, and the main Dockerfile is a two-stage build. The first stage is node:22-alpine, which installs pnpm globally, copies package.json and pnpm-lock.yaml, runs pnpm install, copies the rest of the source and runs pnpm build. The second stage is nginx:stable-alpine, which copies the built application from the build stage into the nginx html directory, removes the default nginx configuration and copies the project's own nginx.conf in its place, then runs nginx in the foreground:

FROM nginx:stable-alpine
COPY --from=build /app/build /usr/share/nginx/html
RUN rm /etc/nginx/conf.d/default.conf
COPY ./nginx/nginx.conf /etc/nginx/conf.d
CMD ["nginx", "-g", "daemon off;"]

That is a static-site deployment. There is no application server in the image and no runtime backend, which tells you the viewer's data is fetched from somewhere else, at runtime, from the browser.

The Dockerfile.cloud variant presumably produces a different flavour of the same thing, though the repository does not document the difference, and the manifests/ directory holds deployment descriptors for the platforms the project targets.

Scripts, conventions and the tooling around the app

The script list is short and says something about the workflow.

There is npm start for the development mode, which the template says opens at http://127.0.0.1:3000, with the page reloading on edits and lint errors shown in the console. There is npm test, which launches the test runner in interactive watch mode. There is npm run build for a production build. And there is npm run lint, which the README describes as linting and formatting the code with eslint and tells you to run it before a commit.

The commit tooling is worth noting because it says how the project is maintained. The badges show a prettier code style, Conventional Commits, and a commitizen-friendly badge, and the repository carries a .commitlintrc.json, a .husky/ directory for git hooks, a .prettierrc.json and an .eslintrc.json with an .eslintignore. There is a .versionrc.json for version management and a CHANGELOG.md.

The npm run commit script runs commitizen to format a Conventional Commit message, and the npm run eject script is the stock template one, which removes the single build dependency and copies webpack, Babel and ESLint configuration into the project. The template is candid that eject is a one-way operation.

For a project that has moved to Vite, eject is almost certainly irrelevant, since there is no single react-scripts dependency left to eject. It is a leftover, and a good example of why the README here should be read as a starting point rather than as current documentation. There is a mise.toml for tool version management and a .vscode/ directory for editor configuration.

Where this project is the wrong choice

Three reasons not to pick this repository, stated plainly.

The first is documentation. If you are evaluating a codebase to fork, the absence of an architecture note, a data source description and a deployment guide is a real cost, and the Create React App text actively misleads, since it describes scripts and a build system the project no longer uses. A fork starts with a documentation debt that someone has to pay down before any feature work.

The second is the data. The viewer is a front end, and the data comes from outside the repository. Nothing in the repository describes where the records come from, how they are refreshed, how the schema is versioned, or what happens when the upstream data changes shape. For a personal reference tool that is fine. For anything where the data model matters, that is a dependency you cannot evaluate from the repository, and the browser-side schema handling in the source is the only place to look.

The third is the build tooling split. The package manifest still marks the project as private with version 1.21.5 while the releases list shows v1.21.1, so the published version and the tagged release are not the same number, which is a small sign that the release and version processes have drifted apart.

None of this makes the project bad. It makes it a community tool with a community repository, which is exactly what a database viewer for a fan community should look like. The evaluation question is whether you are extending it as a community project, in which case the code is a fine starting point, or building something dependable on top of it, in which case the missing documentation and the unpinned data are the real issues to solve first.

Editorial conclusion

Adopt sekai-viewer if you want to explore Project Sekai data in a browser and are comfortable working in a fork of a Create React App layout that has since been rebuilt on Vite. Do not adopt it as a base for a production application without replacing the template documentation, and do not expect it to be a data pipeline, since the data itself comes from elsewhere. Verify first that the data source it renders is still the one you want, that the branch you build from matches your pnpm and Node versions, and that the build output lands where the nginx configuration expects it before you deploy the image.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Sekai-World/sekai-viewer on GitHub