ReinaManager is a desktop application for managing visual novel game libraries, built with Tauri 2 (Rust backend) and React 18 (TypeScript frontend). It provides a comprehensive suite of features including game metadata aggregation from multiple sources (VNDB, Bangumi, Hikarinagi, DLsite, ErogameScape, YMGal, Kungal), game launch and process monitoring with playtime tracking, save data backup/restore, a download and installation pipeline, collection management with drag-and-drop, and cloud synchronization of play status. The architecture follows a clean separation between frontend and backend: the React frontend communicates via typed Tauri IPC through a service layer, while the Rust backend uses SeaORM with SQLite for persistence. The metadata system employs a source adapter pattern for extensibility, and the application is cross-platform (Windows, Linux) with platform-specific optimizations for game launching and monitoring. The codebase is under active development with frequent releases and demonstrates strong engineering practices including a well-structured migration system, a standalone segmented download engine, and a robust OAuth flow.
This repository is a production full-stack application for browsing, searching, downloading, and publishing galgame (visual novel) sticker packs. It is a pnpm monorepo containing a Nuxt 4 SSR frontend (`apps/web`) and a Go Fiber v3 API (`apps/api`) backed by PostgreSQL. The API exposes both internal service endpoints and a public read-only OpenAPI "face" for sticker content, while integrating with external ecosystem services: an OAuth 2.0 identity provider (PKCE, httpOnly session cookies, BFF pattern), a centralized content-addressed image service, a catalog service for games/characters, and a community service for comments, notifications, and reactions. Deployment is Docker images to GHCR via Dokploy, with versioned SQL migrations and GitHub Actions CI building all images on push to the `svelte-kit` branch. The backend is well-layered: handlers own HTTP concerns, services contain business logic without importing Fiber, repositories use GORM, and repeated cross-service communication is isolated in reusable `pkg` clients. Noteworthy engineering includes batch hydration for pack covers/tags/authors, trigram GIN search over flattened multilingual text, cursor pagination for notifications, and RFC 9457 problem-detail error responses in the public API. The frontend is organized into feature modules and includes a race-condition-safe catalog picker, OAuth PKCE utilities, and server-side OG image generation. The codebase is maintained and technically current, though some operational risks remain: dual error dialects between internal and public APIs, silent degradation when optional upstream services are down, and a few hardcoded backfill mappings in one-time scripts.