A transparent discovery signal based on current public GitHub metadata.
Recent activity35% weight
72
Community adoption25% weight
16
Maintenance state20% weight
100
License clarity10% weight
100
Project information10% weight
75
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
README preview
FastAPI Example
Production-ready educational FastAPI service implementing Vertical Slices + CQRS + Onion Architecture patterns. Features async SQLAlchemy 2.0, JWT authentication, dependency injection (Dishka), Redis caching/rate limiting, asynchronous mail notifications via FastStream + Kafka, and comprehensive observability stack (Loki + Promtail + Grafana). Dockerized and fully automated.
High-performance authentication service built with Clean Architecture and CQRS, optimized for extreme read-heavy workloads (1M+ token validations/minute). Features FastAPI + PostgreSQL with functional programming patterns.
Kafka 4.2+ — Event broker for background workflows
MailDev — Local SMTP server + web UI for email testing
Observability
Loki — Log aggregation
Promtail — Log shipper
Grafana — Dashboard & visualization
Development Tools
uv — Ultra-fast Python package manager & runner
Ruff 0.15+ — Fast Python linter & formatter
MyPy 1.19+ — Static type checker
Docker & Docker Compose — Containerization
Architecture
Core Principles
The project implements three complementary architectural patterns for scalability, maintainability, and testability:
Vertical Slices
Features are organized as independent, self-contained vertical slices. Each slice (e.g., users, auth) encapsulates all layers of functionality—from presentation to infrastructure—reducing coupling and enabling independent feature development. Each feature has its own commands/queries and handlers, organized under application/features/{feature}/{operation}/.
CQRS (Command Query Responsibility Segregation)
Requests are split into two types:
Commands — State-changing operations (create, update, delete). Each command is handled by a dedicated handler.
Queries — State-reading operations (get, list). Each query is handled by a dedicated handler.
This separation provides:
Clear intent in code (command vs. query operations)
Optimizable read/write paths independently
Simplified testing and reasoning about side effects
Onion Architecture (Layered)
The codebase is organized in concentric layers, each with well-defined responsibilities:
Commands handle state-changing operations (create, update, delete). Queries handle state-reading operations (get, list). Each is defined as a simple dataclass and executed by a dedicated handler class. Controllers create the appropriate command/query, invoke the handler, and return the response.