Feature Flags Laravel Package

Technical Evaluation

Architecture Fit

• Strengths:

  • Laravel-native integration: Deeply integrates with Laravel’s core components (routes, middleware, query builder, Blade, validations, and task scheduling), reducing boilerplate and ensuring consistency.
  • Pipeline/Gateway architecture: Version 2+ introduces a modular pipeline/gateway system, enabling support for multiple drivers (e.g., database, cache, in-memory) and custom logic (e.g., gates, expiration handlers).
  • Extensibility: Supports custom drivers, middleware, and query builder mixins, making it adaptable to complex feature flagging needs (e.g., A/B testing, gradual rollouts).
  • Debugging tools: Built-in debugging (e.g., feature:state command, fake flags for testing) simplifies troubleshooting and development.
  • Performance: Cache-friendly design (e.g., update_on_resolve config) minimizes database/cache hits for frequently accessed flags.

• Limitations:

  • No built-in UI: While a dashboard (Flagfox) is in development, the package lacks a native admin interface for managing flags, requiring integration with third-party tools (e.g., Laravel Nova, Filament) or custom solutions.
  • Driver dependency: Relies on external storage (e.g., database, Redis) for persistence, which may introduce latency or complexity for simple use cases.
  • Version 3 breaking changes: Migration from v1/v2 to v3 may require refactoring for teams using older versions, though the changelog suggests minimal effort.

Integration Feasibility

• Laravel Compatibility:
  • Officially supports Laravel 10–13 (as of v3.1.0), with backward compatibility for v2.x on Laravel 9+. PHP 8.1+ recommended.
  • Facade-based API: Simple Features::accessible('flag-name') syntax integrates seamlessly with existing Laravel codebases.
  • Middleware/Route Integration: Built-in middleware (FeatureFlagsMiddleware) and route filtering (Features::routeIsAccessible()) enable granular control over feature visibility.
• Database/Storage:
  • Supports multiple drivers (e.g., database, cache, in_memory). Teams using Laravel’s default database or Redis for caching can leverage existing infrastructure.
  • Migration path: Existing feature flag implementations (e.g., custom tables or config files) can be migrated to this package’s pipeline system with minimal effort.
• Query Builder Mixins:
  • Eloquent query methods (whenFeatureIsAccessible()) enable dynamic data filtering without application-layer logic, reducing complexity.

Technical Risk

• Low Risk for Greenfield Projects:
  • Minimal setup (composer install + config publish) and clear documentation reduce onboarding friction.
  • Well-tested (CI/CD pipelines, codecov, and active maintenance) with 600+ stars and recent releases (May 2026).
• Moderate Risk for Legacy Systems:
  • Version upgrades: Teams on Laravel <9 or PHP <8.1 may face compatibility issues. V3’s breaking changes (e.g., pipeline/gateway system) could require refactoring.
  • Custom driver development: Advanced use cases (e.g., multi-tenant flags) may require custom drivers, adding complexity.
  • Cache invalidation: Improper configuration of update_on_resolve could lead to stale flag states in distributed environments.
• Dependencies:
  • Relies on Laravel’s service container and caching system. Teams using non-standard setups (e.g., custom cache drivers) may need adjustments.

Key Questions for TPM

1. Feature Flag Strategy:
   • How will flags be managed (e.g., self-service via UI, manual config, or third-party tools)? The lack of a built-in dashboard may require integration with Filament/Nova or a custom solution.
   • Are flags needed for gradual rollouts, A/B testing, or maintenance mode? The package supports these via gates, pipelines, and middleware.
2. Performance:
   • Will flags be stored in the database, cache, or in-memory? The in_memory driver is fastest but volatile; database/cache drivers add persistence at the cost of latency.
   • How often will flags change? Frequent updates may require tuning update_on_resolve to balance performance and consistency.
3. Testing and Debugging:
   • Does the team need fake flags for testing? The package supports this via Features::fake().
   • Are there requirements for auditing flag access or changes? This would need a custom driver or integration with Laravel’s logging.
4. Scaling:
   • How will flags scale across microservices or multi-region deployments? The pipeline system supports distributed drivers (e.g., Redis), but consistency must be validated.
   • Will flags be user-specific (e.g., role-based)? The package supports gates but may need extension for complex logic.
5. Migration:
   • Are existing feature flags implemented? If so, what’s the effort to migrate to this package’s pipeline system?
   • Is the team using Laravel <9 or PHP <8.1? If yes, v2.x may be more suitable, but v3.x is recommended for long-term support.
6. Monitoring:
   • Are there requirements to track flag usage or performance impact? This would require custom instrumentation (e.g., logging feature:state calls).

Integration Approach

Stack Fit

• Ideal for:
  • Laravel monoliths: Deep integration with routes, middleware, and Eloquent reduces cross-cutting concerns.
  • Feature-driven development: Teams using CI/CD pipelines (e.g., GitHub Actions) benefit from flags enabling/disabling features without deployments.
  • Data-driven rollouts: Supports gradual rollouts via gates (e.g., percentage-based access) and query builder filters.
• Less ideal for:
  • Non-Laravel stacks: PHP/non-Laravel applications would need significant adaptation.
  • Serverless/edge computing: Flags stored in database/cache may introduce latency; edge caching (e.g., Cloudflare) would be needed.
  • Microservices without shared storage: Distributed systems require a shared driver (e.g., Redis) for consistency.

Migration Path

1. Assessment Phase:
   • Audit existing feature flag implementations (e.g., config files, database tables, or third-party tools).
   • Identify gaps (e.g., lack of UI, custom logic) and prioritize requirements (e.g., gradual rollouts vs. simple toggles).
2. Pilot Integration:
   • Start with a non-critical feature to test the package’s in_memory driver (for development) or database driver (for production).
   • Example: Replace a hardcoded if (config('features.new_ui')) with if (Features::accessible('new-ui')).
3. Core Components:
   • Middleware: Replace custom middleware with FeatureFlagsMiddleware for route-level control.
   • Query Builder: Use whenFeatureIsAccessible() in Eloquent queries to filter data dynamically.
   • Scheduling: Leverage Features::scheduleIsAccessible() for task scheduling.
   • Validation: Integrate with Laravel’s validation rules (e.g., FeatureFlagRule).
4. Advanced Features:
   • Custom Drivers: Extend the pipeline for multi-tenant or remote storage (e.g., DynamoDB).
   • Gates: Implement complex logic (e.g., "flag X is on for users in region Y").
   • Fakes: Use Features::fake() in tests to isolate feature behavior.
5. Dashboard Integration:
   • If Flagfox is released, evaluate its fit. Otherwise, integrate with:
     • Filament/Nova: Build a custom resource for flag management.
     • Laravel Horizon: For real-time flag updates (if using queue-based drivers).
6. Deprecation:
   • Phase out legacy implementations (e.g., config files) once the package is fully adopted.

Compatibility

• Laravel Versions:
  • v3.x: Laravel 10–13 (recommended for new projects).
  • v2.x: Laravel 9 (for legacy systems).
  • v1.x: Deprecated (avoid).
• PHP Versions:
  • PHP 8.1+ (required for v3.x; v2.x supports PHP 7.4+).
• Dependencies:
  • No major conflicts with Laravel’s core or popular packages (e.g., Spatie, Laravel Breeze).
  • Potential conflicts: Custom middleware or route filters with overlapping logic may need refactoring.
• Database:
  • Supports MySQL, PostgreSQL, SQLite (via Laravel’s database layer). No schema migrations are required for the in_memory driver.

Sequencing

1. Phase 1: Core Integration (2–4 weeks)
   • Install the package and publish config.
   • Migrate 2–3 critical features to use Features::accessible().
   • Test middleware and route filtering.
2. Phase 2: Advanced Features (2–3 weeks)
   • Implement custom drivers/gates for complex logic.
   • Integrate with query builder and validation.
   • Set up fake flags for testing.
3. Phase 3: Observability (1–2 weeks)
   • Add logging for flag access (e.g., via Laravel’s `