hejmsdz/goslides

Purpose and Entry Points

This is a Go backend for managing church/liturgy content, songs, teams, users, live sessions, and presentation decks. Application startup is rooted at main.go, with HTTP server setup in app/server.go. Dependency construction is centralized in di/dependencies.go.

HTTP API Layer

Feature-specific routers expose the API boundary and translate HTTP requests into service calls:

• Authentication and bootstrap: routers/auth_router.go, routers/bootstrap_router.go

• Liturgy, live operation, and presentation decks: routers/liturgy_router.go, routers/live_router.go, routers/deck_router.go

• Content and administration: routers/songs_router.go, routers/teams_router.go, routers/users_router.go

Routers should remain the request/response boundary; DTOs in dtos/ represent transport-facing payloads and error shapes.

Domain Services

Business workflows are organized by feature in services/. These services are the primary control-flow layer between routers, domain models, repositories, and rendering utilities:

• Authentication, including Google authentication: services/auth_service.go, services/google_auth_service.go

• Liturgy and live-state orchestration: services/liturgy_service.go, services/live_service.go

• Song, team, user, and deck workflows: services/songs_service.go, services/teams_service.go, services/deck_service.go

Persistence and State Boundaries

The repository layer defines persistence abstractions and multiple implementations:

• Liturgy state: repos/liturgy_repo.go, repos/redis_liturgy_repo.go, repos/memory_liturgy_repo.go

• Live-session state: repos/live_repo.go, repos/redis_live_repo.go, repos/memory_live_repo.go

• Authentication nonces: repos/nonce_repo.go, repos/redis_nonce_repo.go, repos/sql_nonce_repo.go

This indicates Redis-backed ephemeral/shared state with memory implementations for local or fallback use, while nonce persistence can use SQL. Database and Redis connection setup are isolated in database/db.go and database/redis.go.

Domain and API Contracts

Domain entities are grouped by business area in models/, including models/live_models.go, models/songs_models.go, and models/teams_models.go. External API contracts are separated into DTO files such as dtos/liturgy_dtos.go, dtos/live_dtos.go, and dtos/deck_dtos.go. This separation is an important boundary: services should map transport DTOs to domain models rather than exposing storage shapes directly.

Rendering and Document Generation

Presentation/document concerns are isolated from HTTP and persistence:

• PDF generation: core/pdf.go

• Typesetting/layout: core/typesetting.go

• Tugal-related rendering/content logic: core/tugal.go

services/deck_service.go likely coordinates deck workflows with these core rendering facilities. Fonts are supplied from fonts/, and generated/public-facing artifacts are expected under public/.

Runtime and Infrastructure

The runtime is Go, defined by go.mod and launched through main.go. Container deployment is supported by Dockerfile; development reload configuration is in .air.toml. External infrastructure materially includes a SQL database, Redis, and Google-based authentication. CI is configured at .github/workflows/ci.yml.