dependency-injection_skill

Overview

This skill documents myfy's constructor-based dependency injection system with three lifecycle scopes: SINGLETON, REQUEST, and TASK. It explains how to declare providers with the @provider decorator, use qualifiers and names, and how modules like WebModule, DataModule, TasksModule, and others commonly rely on DI. The goal is to make dependency patterns explicit, avoid lifecycle mistakes, and speed up correct wiring of services.

How this skill works

Providers are ordinary functions annotated with @provider and a scope; the DI container creates and injects their return values where needed. SINGLETON instances live for the application lifetime, REQUEST instances are created per HTTP request, and TASK instances are created per background task. The container enforces scope rules at startup and supports qualifiers, named providers, reloadable settings, and test-time overrides.

When to use it

• Wiring shared resources like DB pools, HTTP clients, and caches (SINGLETON).
• Creating per-request resources such as DB sessions, request logger, or user context (REQUEST).
• Providing task-scoped items like job context or task-specific loggers (TASK).
• When using @provider, qualifiers, or name-based resolution for multiple providers.
• When writing routes that mix path/query/body params and DI-resolved parameters.

Best practices

• Keep provider functions pure and free of side effects; construct objects only.
• Prefer SINGLETON for connection pools and expensive shared resources. Use REQUEST for request-local state and TASK for background-job state.
• Avoid SINGLETON depending on REQUEST or TASK scoped types; use factory providers to bridge scopes.
• Annotate return types on all providers so the container can resolve types reliably.
• Use qualifiers for multiple providers of the same type and override() in tests for safe mocks.

Example use cases

• Declare a SINGLETON database_pool used by DataModule and Services across the app.
• Create a REQUEST-scoped AsyncSession injected into route handlers for transactional work.
• Provide a TASK-scoped task_logger for background job tracing in TasksModule.
• Expose two Database providers (primary, replica) and inject by Qualifier in different routes.
• Use a singleton factory to produce request-scoped services when a singleton must not capture request state.