Laravel Demo Mode Laravel Package

Technical Evaluation

Architecture Fit

• Lightweight Middleware: The package is a minimal middleware solution, making it a low-overhead addition to Laravel applications. It does not introduce complex dependencies or architectural changes, aligning well with Laravel’s middleware-based routing system.
• Non-Intrusive: Since it operates at the HTTP layer (via middleware), it integrates seamlessly with existing route definitions without requiring modifications to business logic or domain models.
• Use Case Alignment: Ideal for feature flagging, staged rollouts, or client demos where temporary access control is needed without full auth systems. Poor fit for admin panels, sensitive data, or production-grade security (as explicitly warned in the README).

Integration Feasibility

• Laravel Native: Built for Laravel, leveraging its middleware stack (app/Http/Middleware/DemoMode.php). Requires minimal setup (publish config, register middleware in app/Http/Kernel.php).
• Configuration-Driven: Access control is managed via a single config file (demo_mode.php), making it easy to toggle or customize behavior (e.g., demo URL, whitelisted IPs).
• Route Flexibility: Can be applied to specific routes, route groups, or global middleware, offering granular control.

Technical Risk

• False Sense of Security: Middleware alone cannot replace authentication/authorization for sensitive routes. Misuse (e.g., protecting admin panels) could lead to security vulnerabilities.
• State Management: Demo mode relies on session storage (via middleware). If sessions are disabled or shared across environments, behavior may break.
• Deprecation Risk: Package is archived (last release in 2023) with no dependents. Potential for abandonware if issues arise post-integration.
• Edge Cases:
  • How does it handle API routes (e.g., GraphQL, REST)? (Likely works, but undocumented.)
  • Caching: May conflict with route caching (php artisan route:cache) if not handled carefully.
  • Multi-Tenant: Unclear how it behaves in shared-hosting or multi-tenant Laravel apps.

Key Questions

1. Why not use Laravel’s built-in auth middleware or packages like spatie/laravel-permission?
   • If the goal is temporary access control, this package reduces boilerplate. If RBAC is needed, this is insufficient.
2. How will demo mode interact with existing auth systems?
   • Does it bypass auth entirely, or work alongside it? (Risk of conflicts.)
3. What’s the failure mode if the demo URL (/demo) is blocked?
   • Will all routes become inaccessible? Is there a fallback?
4. Performance Impact:
   • Does the middleware add measurable overhead? (Likely negligible, but worth benchmarking.)
5. Long-Term Maintenance:
   • Since the package is archived, who will support it if bugs emerge? Plan for forks or alternatives (e.g., custom middleware).

Integration Approach

Stack Fit

• Laravel Ecosystem: Perfect fit for Laravel apps (v7+). No conflicts with core Laravel features.
• Complementary Packages:
  • Works alongside spatie/laravel-activitylog, spatie/laravel-permission, or laravel/breeze (but not as a replacement).
  • Could integrate with feature flags (e.g., spatie/laravel-flash) for staged releases.
• Non-Laravel: Not applicable—hard dependency on Laravel’s middleware system.

Migration Path

1. Installation:

   composer require spatie/laravel-demo-mode
   php artisan vendor:publish --provider="Spatie\DemoMode\DemoModeServiceProvider"
   

2. Configuration:
   • Update config/demo_mode.php to set demo_url (e.g., /demo) and under_construction_url (e.g., /under-construction).
   • Optionally whitelist IPs or routes.
3. Middleware Registration: Add to app/Http/Kernel.php:

   protected $middleware = [
       // ...
       \Spatie\DemoMode\Middleware\DemoMode::class,
   ];
   

   Or apply to specific routes:

   Route::middleware(['demo'])->group(function () {
       // Protected routes
   });
   

4. Testing:
   • Verify demo mode works by accessing /demo before protected routes.
   • Test edge cases (e.g., cached routes, API calls).

Compatibility

• Laravel Versions: Tested on Laravel 7–9 (check composer.json constraints).
• PHP Versions: Requires PHP 7.3+ (aligns with Laravel’s support).
• Dependencies: No external services or databases—purely HTTP/middleware-based.
• Caveats:
  • May conflict with custom middleware that modifies $request or $response in the same phase.
  • Session drivers: Ensure SESSION_DRIVER is configured (e.g., file, database).

Sequencing

1. Pilot Phase:
   • Use in development/staging first to validate behavior.
   • Monitor for conflicts with existing middleware (e.g., auth, throttle).
2. Production Rollout:
   • Deploy to a non-critical environment (e.g., client demo server).
   • Use feature flags to toggle demo mode dynamically.
3. Decommissioning:
   • Remove middleware from Kernel.php and routes.
   • Clean up published config if no longer needed.

Operational Impact

Maintenance

• Low Effort:
  • Single config file (demo_mode.php) for adjustments.
  • No database migrations or schema changes.
• Monitoring:
  • Log access to /demo and /under-construction for auditability.
  • Track 404s or redirects to identify misconfigured routes.
• Updates:
  • No updates expected (package is archived). If issues arise, consider:
    • Forking the repo.
    • Replacing with a custom middleware solution.

Support

• Documentation: README and config file are sufficient for basic use.
• Community: Limited (294 stars, no dependents). Issues may go unanswered.
• Workarounds:
  • For advanced use cases (e.g., IP whitelisting), extend the middleware:

    namespace App\Http\Middleware;
    use Spatie\DemoMode\Middleware\DemoMode as BaseDemoMode;
    class CustomDemoMode extends BaseDemoMode {
        public function handle($request, Closure $next) {
            // Add custom logic (e.g., IP checks)
            return parent::handle($request, $next);
        }
    }
    

Scaling

• Performance:
  • Minimal overhead (single middleware check per request).
  • No database or external API calls.
• Horizontal Scaling:
  • Stateless (relies on session storage), so scales with Laravel’s session drivers.
  • No distributed locking or cache invalidation needed.
• Load Testing:
  • Verify under high traffic that session storage (e.g., Redis) doesn’t become a bottleneck.

Failure Modes

Ramp-Up

• Onboarding Time: <1 hour for basic setup.
• Team Training:
  • Educate devs on when to use (non-sensitive routes) and when not to (admin, sensitive data).
  • Document the /demo URL and access flow for clients.
• Client Communication:
  • Clearly explain that demo mode is temporary and not secure.
  • Provide instructions for accessing the demo (e.g., "Visit /demo first").