// the find
KunMoe/kun-galgame-forum
The CUTEST visualnovel / galgame forum! Built with Nuxt4, GO Fiber and PostgreSQL. Kun Visual Novel forum 6th generation! 开源, 免费, 零门槛, 最先进的 Galgame 论坛社区!
A full-featured forum platform built specifically for the visual novel / galgame community, combining a discussion board, community-driven game database with VNDB integration, resource sharing, and a reputation system. It's a production system running at kungal.com, not a demo — the 6th-generation rewrite of an existing community. Relevant to developers who want a reference for a Go + Nuxt SSR monorepo with real-world complexity, or who are building niche community platforms.
The domain module structure in the Go backend is clean — each feature (galgame, topic, message, search) owns its own handler/service/repository/dto stack, which makes the codebase navigable despite its size. Raw SQL migrations with up/down files is the right call over GORM AutoMigrate for a production schema this complex. The infrastructure dependency graph is honest: Meilisearch for search, Redis for cache, S3-compatible storage, and a separate OAuth service are all named up front rather than hidden behind abstractions. The backfill command pattern (a dozen small `cmd/backfill-*` binaries) is a good model for handling schema migrations that require data transformation without downtime.
The project now requires the `kun-galgame-infra` monorepo to run, which isn't in this repo — OAuth, image service, and the Galgame wiki service are all external dependencies with no stubs or mocks provided, making local development genuinely painful for anyone outside the core team. The AI-assisted development note starting at v5.1.0 is honest but the code quality delta is unverifiable from the outside, and vibe-coded Go is a specific kind of risk (plausible-looking but subtly wrong concurrency or error handling). Tests are sparse — a handful of unit tests and no integration test setup in the repo means you're mostly trusting the live site as the test harness. The monorepo tooling (pnpm workspaces coordinating Go and Node builds) adds friction without obvious benefit over just two separate repos with a shared CI pipeline.