Split the monolithic server API module into domain routers #19

New Issue

Francy51 · 2026-03-15T01:26:00Z

Francy51 commented

2026-03-15 01:26:00 +00:00

The main Elysia API surface is concentrated in a single large module, which is becoming a maintainability bottleneck.

Why this is a problem:

lib/server/api/app.ts currently owns route definitions, parsing helpers, and domain orchestration across many features.
The file is large enough that changes are harder to review safely.
Cross-cutting edits are more likely to introduce regressions.
This slows down long-term maintainability, which the repo explicitly prioritizes.

Observed in:

lib/server/api/app.ts is ~1800 lines and spans auth, watchlist, portfolio, filings, research, search, tasks, and analysis concerns.

Suggested direction:

Split the API into domain routers/modules with minimal shared plumbing.
Move input coercion/validation and domain-specific orchestration closer to each feature.
Keep shared helpers focused and small.
Preserve current API behavior while reducing route-surface coupling.

Acceptance criteria:

Major API domains are split into separate route modules.
Shared helpers remain reusable without centralizing unrelated concerns.
Behavior stays stable and tests cover the extracted routing boundaries.

The main Elysia API surface is concentrated in a single large module, which is becoming a maintainability bottleneck. Why this is a problem: - `lib/server/api/app.ts` currently owns route definitions, parsing helpers, and domain orchestration across many features. - The file is large enough that changes are harder to review safely. - Cross-cutting edits are more likely to introduce regressions. - This slows down long-term maintainability, which the repo explicitly prioritizes. Observed in: - `lib/server/api/app.ts` is ~1800 lines and spans auth, watchlist, portfolio, filings, research, search, tasks, and analysis concerns. Suggested direction: - Split the API into domain routers/modules with minimal shared plumbing. - Move input coercion/validation and domain-specific orchestration closer to each feature. - Keep shared helpers focused and small. - Preserve current API behavior while reducing route-surface coupling. Acceptance criteria: - Major API domains are split into separate route modules. - Shared helpers remain reusable without centralizing unrelated concerns. - Behavior stays stable and tests cover the extracted routing boundaries.

Francy51 added the P1 label 2026-03-15 01:26:00 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Francy51/Neon-Desk#19