Skip to content

[backend] Standardize data access through contexts/ layer #205

@JonnyTran

Description

@JonnyTran

Problem

The backend has two patterns for DB access. The contexts/ package owns ~66 query operations, but ~22 endpoints in api/handlers/v1/ still call SQLAlchemy directly (.execute() / .filter()). Same operations are reimplemented in both places, no single source of truth for query logic, and authorization/validation that lives in contexts is bypassed by inline queries.

Goal

All DB access from handlers goes through contexts/. Handlers stay thin: parse input → call context → shape response.

Approach

  1. Audit handlers under extralit-server/src/extralit_server/api/handlers/v1/ for direct SQLAlchemy usage. Produce a list (handler → operation).
  2. For each, either reuse an existing contexts/<module> function or add one.
  3. Replace inline queries with the context call.
  4. Add a CI lint (ruff custom rule or grep check) that fails when handler files import from sqlalchemy or models/.

Out of scope

Restructuring contexts/ itself — this is purely about routing handlers through the existing layer.

Acceptance criteria

  • grep -rn "session.execute\|session.scalars" src/extralit_server/api/handlers/v1/ returns nothing.
  • Handler files don't import from sqlalchemy or extralit_server.models directly.
  • Existing test suite passes; no new behavior change.

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendrefactorCode refactoring or technical debt improvements

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions