Skip to content

Router File Splitting

How BlueClerk organizes large backend files for better maintainability

Overview

BlueClerk's backend code is organized into smaller, focused files to improve maintainability and development speed. This "file splitting" approach keeps related functionality together while preventing individual files from becoming too large to navigate or debug effectively.

Why File Splitting Matters

Developer Benefits

  • Faster navigation - Find relevant code quickly without scrolling through thousands of lines
  • Easier debugging - Smaller files mean clearer stack traces and faster issue isolation
  • Better code review - Reviewers can focus on specific feature areas without overwhelming context
  • Reduced merge conflicts - Changes to different features rarely touch the same file

File Organization Strategy

BlueClerk splits backend code by:

  • Feature domain - Customer queries, job operations, invoice actions
  • Operation type - Queries vs mutations vs helper functions
  • Shared types - Common TypeScript types used across multiple files

Common Split Patterns

Router Files

Large tRPC routers are split into:

  • Query files - Read operations (customer-queries.ts, ticket-queries.ts)
  • Mutation files - Write operations (invoice-actions.ts, estimate-actions.ts)
  • Helper files - Shared logic (job-queries-mine-helpers.ts)
  • Type files - TypeScript interfaces (estimate-action-types.ts, worker-job-detail-types.ts)

AI Tool Files

AI chat tools are organized by:

  • Catalog operations - Item search, creation, updates (chat-tools-catalog-mutations.ts)
  • Core mutations - Invoice/estimate/ticket creation (chat-tools-mutations.ts)
  • Helper utilities - Customer linking, deduplication logic

Frontend Components

UI components split by:

  • Feature boundaries - Invoice prompts, job detail modals
  • Shared types - Component prop interfaces
  • Modal content - Dialog components separated from page components

What This Means for You

If You're a User

You won't notice file splitting directly - it's a behind-the-scenes improvement. What you WILL notice:

  • Faster bug fixes - Developers can locate and fix issues more quickly
  • More reliable features - Smaller files mean fewer unintended side effects from changes
  • Smoother updates - Less risk of breaking unrelated features during deployments

If You're a Developer

When contributing to BlueClerk or reviewing code:

  • Check existing patterns - Follow the split structure already in place
  • Keep files focused - If a file grows beyond ~500 lines, consider splitting
  • Use descriptive names - File names should clearly indicate what they contain
  • Maintain imports - Update import paths when files are reorganized

Questions

Q: Why not just keep everything in one big file? A: Large files (2000+ lines) become unmanageable - finding specific functions takes longer, merge conflicts are more common, and it's harder to reason about what the code does. Splitting improves both developer experience and code quality.

Q: Does file splitting affect app performance? A: No. File organization is a development-time concern - the production build bundles everything efficiently regardless of how source files are structured.

Q: How do I know which file contains the code I need? A: Look at file names and folder structure. Queries go in -queries.ts files, mutations in -actions.ts or -mutations.ts, and shared types in -types.ts. When in doubt, search the codebase by function or component name.

Was this helpful?
Contact Support →