Feature Flags Laravel Package

Technical Evaluation

Architecture Fit

• Strengths:

  • Deep Laravel integration (routes, Blade, query builder, validations, scheduling) aligns with Laravel’s ecosystem.
  • Pipeline/gateway architecture (v2+) enables modularity (e.g., caching, remote storage, gate-based access).
  • Supports feature flagging at multiple layers (code, UI, DB queries), reducing technical debt for gradual rollouts.
  • Debugging tools (e.g., feature:state command, fake flags) simplify testing and observability.
  • Middleware support enables HTTP-level feature gating (e.g., redirecting users if a feature is disabled).

• Weaknesses:

  • No built-in UI dashboard (Flagfox is in waitlist; reliance on third-party tools like Spatie’s Laravel Feature Flags or custom solutions).
  • Driver dependency: Requires configuration of storage backends (e.g., Redis, database, cache) for persistence.
  • Cache invalidation: Manual handling of stale flags if not using a cache driver with proper TTL management.

Integration Feasibility

• Laravel Compatibility:

  • Officially supports Laravel 10–13 (v3.x). Backward compatibility with v2.x for Laravel 9+.
  • PHP 8.1+ required (type hints, strict mode).
  • No framework bloat: Lightweight (~10K LOC) with minimal core dependencies.

• Key Integrations:

  • Eloquent Query Builder: whenFeatureIsAccessible()/whenFeatureIsNotAccessible() for conditional queries.
  • Validation: FeatureFlagRule for form-level gating.
  • Scheduling: shouldRun() for task scheduling.
  • Blade: @if(Features::accessible('flag')) directives.
  • Middleware: FeatureFlagMiddleware for route-level access control.

• Non-Laravel Systems:

  • APIs: Works with Laravel Sanctum/Passport for token-based flag evaluation.
  • Frontend: Flags can be exposed via API (e.g., GET /api/features) for SPAs.
  • CI/CD: Fake flags enable safe deployment testing (e.g., Features::fake('new-feature', true)).

Technical Risk

• Critical Risks:

  • Cache stampedes: If using in-memory drivers, flag evaluation could become a bottleneck under high traffic.
  • Driver misconfiguration: Incorrect TTL settings or stale cache may lead to inconsistent flag states.
  • Middleware order: FeatureFlagMiddleware must be placed before route resolution to block access early.

• Mitigation Strategies:

  • Use Redis/Memcached for distributed cache with proper TTL (e.g., 5–10 minutes).
  • Monitor cache hits/misses via Laravel’s cache driver stats.
  • Test edge cases: Race conditions during flag toggles (e.g., using Features::fake() in tests).
  • Fallback drivers: Configure a chain driver to fall back to a database if cache fails.

• Open Questions:

  • Flag persistence: Will flags be stored in a database, Redis, or config files? What’s the recovery plan for driver failures?
  • A/B testing: Does the package support percentage-based rollouts (e.g., 10% of users see Feature X)? If not, will a custom driver be needed?
  • Audit logging: Are there plans to log flag access/changes for compliance? If so, how will this be implemented?
  • Performance: Under what traffic levels has this package been stress-tested? Are there benchmarks for cache vs. DB drivers?
  • Upgrade path: If migrating from v1/v2, what’s the effort to adopt v3’s pipeline architecture?

Integration Approach

Stack Fit

• Ideal for:

  • Laravel monoliths with complex feature rollout needs (e.g., SaaS, marketplaces).
  • Teams using GitOps/CD: Flags enable safe, incremental deployments without merging code.
  • Data-driven rollouts: Combine with analytics (e.g., Mixpanel) to track flag impact.
  • Microservices: Use the API to sync flags across services (e.g., via Redis pub/sub).

• Less Ideal for:

  • Static sites or non-Laravel backends (e.g., Node.js, Python).
  • Simple projects where feature toggles aren’t justified (overhead of configuration).
  • Real-time systems where low-latency flag evaluation is critical (e.g., trading platforms).

Migration Path

1. Assessment Phase:

   • Audit existing feature toggles (if any) and map them to the package’s syntax.
   • Decide on storage driver (e.g., Redis for performance, DB for persistence).
   • Plan for testing infrastructure (fake flags, middleware mocks).

2. Pilot Phase:

   • Start with non-critical features (e.g., admin-only toggles).
   • Implement flag-driven routes and Blade conditionals.
   • Test query builder methods (whenFeatureIsAccessible()) in critical paths.

3. Full Adoption:

   • Replace custom flag implementations with the package’s facade (Features::accessible()).
   • Migrate validation rules and scheduling logic to use the package.
   • Integrate with CI/CD (e.g., fake flags in staging environments).

4. Optimization:

   • Benchmark cache vs. DB drivers under production load.
   • Implement flag expiration handlers for time-bound features.
   • Set up monitoring for flag access patterns (e.g., Prometheus metrics).

Compatibility

• Laravel Versions:

  • v3.x: Laravel 12–13 (PHP 8.1+).
  • v2.x: Laravel 9–11 (PHP 8.0+).
  • v1.x: Deprecated (Laravel 6–8).

• Dependencies:

  • Core: PHP 8.1+, Laravel 10+.
  • Optional: Redis, database, cache drivers (e.g., predis/predis for Redis).
  • Testing: PHPUnit, Pest (for fake flag testing).

• Conflicts:

  • Avoid naming collisions with existing Feature models/classes.
  • Ensure middleware priority is set correctly (e.g., FeatureFlagMiddleware should run early).

Sequencing

1. Installation:

   composer require ylsideas/feature-flags:^3.0
   php artisan vendor:publish --provider="YlsIdeas\FeatureFlags\FeatureFlagsServiceProvider" --tag=config
   

2. Configure:
   • Set default driver (e.g., cache, database, or chain).
   • Define features.php flags (e.g., new-payments-system: false).
3. Test:
   • Use Features::fake('flag', true) in tests.
   • Verify middleware, validation, and query builder integrations.
4. Deploy:
   • Roll out flag-driven routes/Blade templates first.
   • Gradually enable critical features via flags.

Operational Impact

Maintenance

• Pros:

  • Centralized configuration: All flags managed in config/features.php or a database.
  • Type safety: PHP 8.1+ type hints reduce runtime errors.
  • Extensible: Custom drivers/gateways can be added (e.g., for SSO-based access).
  • Community support: 600+ stars, active maintenance (releases every 2–3 months).

• Cons:

  • Driver management: Requires monitoring of cache/DB health for flag persistence.
  • Documentation gaps: Flagfox dashboard is in waitlist; no official UI for non-developers.
  • Deprecation risk: Laravel 13+ compatibility is new (v3.1.0); long-term support unclear.

Support

• Troubleshooting:

  • Flag not updating? Check cache TTL or driver connection.
  • Middleware blocking routes? Verify middleware priority in app/Http/Kernel.php.
  • Query builder methods not working? Ensure the package’s service provider is registered.

• Debugging Tools:

  • php artisan feature:state to inspect flag values.
  • Features::fake() for local testing.
  • Log flag access via custom gateways (e.g., LogFeatureAccessGateway).

• Escalation Path:

  • GitHub issues for bugs (response time: ~1–3 days based on activity).
  • Community Slack/Discord (if available) for best practices.

Scaling

• Performance:

  • Cache drivers (Redis/Memcached) scale horizontally with Laravel’s cache layer.
  • Database drivers: Add read replicas for high-throughput flag checks.
  • Pipeline optimization: Order drivers by speed (e.g., cache first, DB fallback).

• Load Testing:

  • Simulate 10K+ RPS to validate cache performance.
  • Monitor Features::accessible() latency under load (target: <5ms p99).

• **Failure M