PubTrivia database schema declared twice with 126 diff lines
PubTrivia splits its Next.js app and WebSocket server, leading to duplicated Drizzle database schemas across packages where all 126 diff lines are just comments.
Stock photo for illustration only, not from the actual event
- PubTrivia completely separates its Next.js application and WebSocket server.
- Database schemas are duplicated across two files due to deployment constraints.
- A diff check reveals 126 differing lines, all of which are code comments.
- The structure and data types of all 8 shared tables match 100% perfectly.
The PubTrivia project operates by running its main application built with Next.js on one host, while a long-running WebSocket process managing sockets and the game clock runs on another host. Both parts deploy from the same repository but as separate packages, causing the WebSocket build process to see only the ws-server/ directory without access to the workspace root or schema imports.
This reasonable deployment architecture introduces the necessity to declare the database schema twice. Both files begin by informing readers about the other file using different wording, explicitly stating that the copy is intentional because the standalone process cannot import packages from the parent directory.
Because comments are not execution mechanisms, the developer measured how far apart the two copies drifted by parsing both files with a script extracting every pgTable and column type. The results showed that out of the eight shared tables, zero columns had differing types, ensuring zero runtime breaks.
Stock photo for illustration only, not from the actual event
The main app declares three extra tables that the socket process ignores, such as privacy audit trails, login sessions, and team memberships. Because the game process never reads them, copying those tables would be pointless, meaning the duplicate file serves as a clean subset rather than a divergent variant.
Schema duplication in a monorepo or microservices architecture often arises when isolating standalone services for deployment flexibility. While this avoids cross-package import hurdles, maintaining strict synchronization remains a primary engineering challenge as systems evolve.
The remaining differences consist almost entirely of inline documentation comments explaining column reasoning, such as nullable statuses or trial defaults. The copied schema strips away these comments entirely, leaving fewer explanation lines compared to the main application file.
Failure modes remain strictly bounded by architectural constraints because the Drizzle configuration explicitly targets a single schema file path. Without configuration files or migration tools in the socket server package, code divergence can never alter the production database, leaving only the risk of misreading data.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment