Skip to content

Refactor Server struct to separate concerns and improve testability #271

Description

@danieljustus

Goal

Extract concerns from the Server struct into separate middleware/handler structs and create a MemoryService for business logic.

Why now

Surfaced by a code review on 2026-06-25 in category "Architecture". Estimated effort/impact: High effort / high impact.

Current state / Evidence

internal/mcp/server.go:15-26 — The Server struct holds references to the database, JWT provider, embeddings generator, pattern extractor, rate limiter, config, profile, and CORS origins. It's responsible for HTTP routing, authentication, CORS, rate limiting, and all business logic handlers. This makes testing difficult and violates single responsibility.

References:

  • internal/mcp/server.go:15-26
  • internal/mcp/handlers.go:1-447

In Scope

  • Extract AuthMiddleware for JWT authentication and role-based access
  • Extract CORSMiddleware for origin validation and headers
  • Create MemoryService that encapsulates business logic (search, set, delete)
  • Have HTTP handlers be thin wrappers that delegate to the service
  • Improve testability by allowing dependency injection
  • Add unit tests for each extracted component

Out of Scope

  • Changes to the HTTP API contract
  • Changes to the database schema
  • Changes to the MCP server protocol

Acceptance criteria

  • AuthMiddleware handles JWT authentication and role checks
  • CORSMiddleware handles origin validation and headers
  • MemoryService encapsulates all business logic
  • HTTP handlers are thin wrappers (~10-20 lines each)
  • Each component can be tested independently
  • Existing tests continue to pass
  • New unit tests verify middleware and service behavior

Risks / Dependencies

This is a significant refactoring that may affect multiple files. Should be done incrementally with thorough testing at each step.

Source

Review file: .github/review/2026-06-25T09-55-13Z.md
HEAD at review: 8499e131b1ea47fffff2d64d760e08f2055543f4

Metadata

Metadata

Assignees

Labels

featureNew capability or enhancementgroup: architectureArchitecture improvements to be planned and implemented togetherpriority: mediumMedium priority work

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions