Files
query-orchestration/api/queryAPI
Jacob Mathison 8a4029058b Merged in jmathison/demo-table (pull request #213)
Add demo dashboard settings table and CRUD API

* Add demo dashboard settings table and CRUD API

- Migration 00000000000123: create demoDashboardSettings table (id, guid, key, value JSONB, isDeleted, timestamps)
- SQLC queries and repository for create, list, listByGuid, get, update, soft delete
- OpenAPI paths and schemas in queryAPI.yaml; regenerate api.gen.go (embedded spec)
- Handlers in api/queryAPI/demodashboardsettings.go; ConfigProvider GetDBQueries for repo access
- Unit tests for demo dashboard settings CRUD

* Fix sqlc-generated demo dashboard setting types

Align demo dashboard settings handlers with sqlc output (DemoDashboardSetting model + pointer slices) so CI codegen/build succeeds.

* Fix CI gosec and gofmt issues

- Suppress gosec G115 for TotalCount len->int32 cast (consistent with other list endpoints)
- gofmt mock GetDBQueries() in test helpers

* gofmt query API demo settings

* Tighten demo dashboard settings OpenAPI constraints

* Regenerate query API embedded spec

* refactor: generic UI settings (table, API, service) and three-layer architecture

- Replace demo-dashboard-settings with generic UI settings:
  - Table uiSettings with namespace (was guid), key, value JSONB; UNIQUE(namespace, key)
  - Migration 123: create_ui_settings (single migration, no rename)
  - OpenAPI: /ui-settings, UISettingsService, UISetting schemas with namespace
  - API types and handlers: CreateUISetting, ListUISettings, GetUISetting, UpdateUISetting, DeleteUISetting

- Add service layer (architecture fix):
  - internal/uisettings: Service with Create, List, ListByNamespace, Get, Update, SoftDelete
  - Controllers call s.svc.UISettings only; remove GetDBQueries from queryAPI ConfigProvider
  - Wire UISettings in Services, main.go, and testutils

- Repository: uisettings.sql + uisettings.sql.go, UISetting model; remove demodashboardsettings
- Controller: uisettings.go (replaces demodashboardsettings.go), ErrNotFound from uisettings package
- Tests: uisettings_test.go with namespace-based list/cre…
* Add UISetting model and generated queries for uiSettings table

- models.go: add UISetting struct (sqlc 1.30.0)
- uisettings.sql.go: generated CRUD for ui_settings feature

Made-with: Cursor

* Use repository.UiSetting to match sqlc-generated type

- service and API use repository.UiSetting (sqlc struct name for uiSettings table)
- uisettings.sql.go: keep CreateUISetting/GetUISetting etc. from query names, return *UiSetting
- Fixes Docker/CI build undefined repository.UISetting

* Fix import formatting for golangci-lint

* Lint fix

* uisettings list test

* tests fixes

* Merge main: resolve api.gen.go conflicts (UI settings + DeleteDocument)

* Doc updates and elimination of index redundancy


Approved-by: Jay Brown
2026-03-04 23:00:50 +00:00
..
2025-08-06 15:06:18 -07:00
2025-08-06 15:06:18 -07:00
2025-07-22 10:29:44 -07:00

queryAPI Package

This directory contains the REST API implementation for the Query Orchestration platform. The code here serves as the HTTP interface layer between external clients and the internal business logic.

Architecture Overview

Controllers Struct (controllers.go)

The Controllers struct is the central architectural component that implements the Service Layer/Facade pattern for the entire REST API.

Purpose

  • OpenAPI Contract Implementation: Implements the ServerInterface interface generated from serviceAPIs/queryAPI.yaml
  • Service Aggregation: Consolidates 11 different business services into a single, cohesive API layer
  • Dependency Injection Container: Provides clean separation between HTTP handlers and business logic

Structure

type Controllers struct {
    svc *Services           // Aggregated business services
    cfg ConfigProvider     // Combined auth & object storage configuration
}

Pattern Benefits

  1. Single Responsibility: Each handler method focuses solely on HTTP↔Service translation
  2. Testability: Services can be easily mocked for unit testing
  3. Modularity: New services can be added without changing the controller pattern
  4. Type Safety: Ensures compile-time checking against OpenAPI specification

Key Architectural Components

1. Generated Code (api.gen.go)

  • DO NOT EDIT: This file is auto-generated from serviceAPIs/queryAPI.yaml
  • Contains all request/response types and the ServerInterface interface
  • Regenerated via task generate command
  • Ensures API contract consistency

2. Handler Files

Each file implements specific domain endpoints:

  • client.go - Client management operations
  • collector.go - Query collector configuration
  • documents.go - Document upload and management
  • export.go - Export operations
  • query.go - Query execution and management
  • status.go - Health check and status endpoints
  • authHandlers.go - Authentication flow handlers (login, logout, callbacks)

3. Service Dependencies

The Controllers struct aggregates these internal services:

  • Export Service - Manages export processes
  • Collector Service - Handles query collections
  • Query Service - Query execution logic
  • Client Service - Client entity management
  • Document Service - Document processing
  • DocumentUpload Service - S3 upload handling
  • DocumentBatch Service - Batch document operations

4. Authentication Integration

  • Uses AWS Cognito for JWT-based authentication
  • Permit.io integration for RBAC (Role-Based Access Control)
  • Authentication middleware validates tokens before reaching handlers
  • ConfigProvider interface provides auth configuration access

Handler Pattern

All handlers follow a consistent pattern:

func (s *Controllers) HandlerName(ctx echo.Context, params...) error {
    // 1. Bind/validate request data
    req := RequestType{}
    if err := ctx.Bind(&req); err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, err)
    }
    
    // 2. Call appropriate service method
    result, err := s.svc.ServiceName.Method(ctx.Request().Context(), ...)
    if err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, "Error message")
    }
    
    // 3. Return formatted response
    return ctx.JSON(http.StatusOK, ResponseType{...})
}

Testing Structure

  • *_test.go files provide unit tests for each handler group
  • test_helpers.go contains shared test utilities and fixtures
  • Tests use mocked services to validate handler logic in isolation
  • Integration tests exist at the service layer level

Important Notes for Maintenance

  1. OpenAPI-First Development: Always update serviceAPIs/queryAPI.yaml first, then regenerate code
  2. Service Layer Separation: Business logic belongs in internal/ services, not in handlers
  3. Error Handling: Use Echo's HTTPError for consistent error responses
  4. Context Propagation: Always pass ctx.Request().Context() to service methods for proper cancellation
  5. No Direct Database Access: All data operations must go through service layer
  6. Consistent Status Codes: Follow REST conventions (201 for creation, 200 for success, 400 for client errors)

Development Workflow

  1. Modify OpenAPI spec in serviceAPIs/queryAPI.yaml
  2. Run task generate to update generated code
  3. Implement/update handler methods in Controllers
  4. Add/update tests for new functionality
  5. Run task lint to ensure code quality
  6. Run task test:functional to validate changes

Configuration

The ConfigProvider interface combines:

  • Authentication configuration (Cognito settings, JWT validation)
  • Object storage configuration (S3 bucket settings)
  • Base service configuration (ports, logging, database)

This unified configuration is injected into Controllers at startup, providing all necessary runtime settings.