Hardcoded feature checks scatter across your frontend. Environment differences cause confusion. Deployments mismatch. Every new feature requires frontend updates.

The feature advertisement pattern solves this: backend advertises capabilities, frontend adapts. No feature list maintained on frontend. No environment-specific code. Just ask: “Do you have X?”

Architecture

Backend maintains a feature enum and registry. Configuration controls which features are enabled. Frontend fetches the list once at startup and checks dynamically.

┌─────────────┐  GET /api/features  ┌─────────────┐
│  Frontend   │────────────────────►│   Backend   │
│             │◄────────────────────│             │
│   Adapts    │   {features...}     │  Advertises │
└─────────────┘                     └─────────────┘

Backend: Define Features

# features.py
from enum import Enum

class Feature(str, Enum):
    ADVANCED_SEARCH = "advanced_search"
    EXPORT_PDF = "export_pdf"
    BULK_OPERATIONS = "bulk_operations"
    REAL_TIME_NOTIFICATIONS = "real_time_notifications"

Single source of truth. Backend only.

“It works on my machine.” “I thought we deployed that fix.” “Which commit is in prod?” “Is staging up to date?”

Version tags like v1.2.3 can point to multiple commits. Tags move. Tags get retagged. Git hashes don’t. Same hash equals identical code, guaranteed. Cryptographic proof.

The solution: Every service exposes a /version endpoint returning its git hash. Instantly verify what’s deployed.

Backend: Capture Hash at Build Time

Docker images don’t contain .git directories. Capture the hash during build and bake it into the image: