Engineering case study

How this site is built

Engineering case study of a production-minded portfolio and publishing platform: architecture, localization, content authoring, quality, security, and infrastructure.

Source code Open the matrix

Problem

The site combines articles, a competency matrix, and architecture notes. It needs to help readers, stay comfortable for authoring, and demonstrate real engineering decisions instead of only listing technologies.

Architecture

Backend

Litestar, SQLAlchemy, Dishka, and PostgreSQL form an API-first backend with explicit boundaries between domain logic, HTTP, infrastructure, and storage. Articles, the competency matrix, team administration, and operational tools keep their own contracts, while shared mechanisms stay below the transport boundary. Shared Swagger at /api/docs and OpenAPI at /api/openapi.json combine the external APIs of all services, including authenticated Personal Workspace operations.

LitestarSQLAlchemyPostgreSQLDishkaTaskIQ

Frontend

Angular hybrid SSR/CSR and backend-driven i18n provide SEO for public pages, while read-only matrix and article surfaces stay separate from protected workspaces: owner, admins, and moderators manage content, while owner and admins govern the team.

AngularSSRTypeScriptBootstrap

Infrastructure

nginx, Docker, MinIO with S3-compatible media storage, Valkey, and TaskIQ separate edge routing, files, cache, background jobs, and frontend/backend container runtimes, while public traffic switches between blue/green slots only after health checks pass. For public media, PostgreSQL tracks the reference lifecycle, while a background TaskIQ job safely removes unused objects after a configurable retention period and retries failed operations. The edge nginx self-recovers after a sustained local liveness failure and uses a restart policy for Docker daemon or VPS restarts.

nginxDockerMinIOValkeyGitHub Actions

Personal API access

Named personal tokens let scripts and AI agents use the regular APIs on a user's behalf. Each token is bounded by selected operations, expiration and the account's current role, and can be revoked independently. Creating, showing and copying a token requires a password. API documentation describes the available operations.

Litestar RESTBearerPATGranular permissions

Engineering decisions

Clean Architecture keeps domain logic independent from Litestar, SQLAlchemy, and external services.
RU/EN localization is split between the UI catalog and content fields, so interface text is not mixed with articles and matrix content.
Anonymous analytics show trends in article and matrix reading and public site visits. Browser identifiers rotate daily; IPs, accounts and full referrer URLs are not stored.
Deployment is treated as a controlled release process with a manual trigger: runtime configuration is rendered from a manifest, CI quality gates are decoupled from the deploy workflow, manual approval on the production environment remains explicit, and blue/green switching with health checks lowers rollout risk.

Quality and operations

Quality is covered by short checks: style, types, unit/integration tests, security, SSR smoke, performance, and SQL plans. They remain CI release evidence, while production deploy runs manually and switches blue/green traffic only after health checks pass. In operations, background jobs, cache, files, and runtime containers have separate responsibilities; public assets are served with CSP and immutable caching.

What is next

Near-term work includes RSS/Atom, a public roadmap, and continued work on observability, performance, and content quality.

Go to articles