Laravel Blink Laravel Package

Getting Started

Blink is available via composer require spatie/laravel-blink. Once installed, it’s ready to use immediately—no config changes or service registration needed. The package registers a Blink service and facade, so you can start caching per-request data right away in your controllers, services, or view composers:

use Spatie\Blink\Blink;

// Using the facade
Blink::put('user_preferences', $this->fetchUserPreferences());

// Using the instance via the container (e.g., in a controller)
$blink = app(Blink::class);
$items = $blink->remember('expensive_query', fn () => HeavyModel::with('relations')->get());

The first use case is usually avoiding repeated lookups of expensive or frequently used data within a single request—like config derived from a database row or computed context for a layout.

Implementation Patterns

• Memoization with remember(): Wrap expensive closures to compute once per request. Blink caches the result and returns it on subsequent calls for the same key.

  $user = Blink::remember('user_'.$userId, fn () => User::with('roles', 'permissions')->findOrFail($userId));
  

• Shared context across layers: Store computed data (e.g., request metadata, permission sets, sidebar config) once in a middleware or service and reuse it in views or downstream classes.

  // In a middleware
  Blink::put('current_route_name', Route::currentRouteName());
  // Later in a view composer
  $view->with('routeName', Blink::get('current_route_name'));
  

• Service-layer caching: In long-running tasks like queue jobs or command handlers, use Blink to avoid recomputing intermediate results—but note Blink does not persist across requests or jobs; each job boots a fresh instance.
• Lightweight state in view composers: Avoid querying the same relations in multiple composers by storing shared computed values once.

  View::composer('*', function ($view) {
      $view->with('navItems', Blink::remember('nav_items', fn () => Navigation::build()));
  });
  

Gotchas and Tips

• Request-scoped only: Blink data does not survive beyond the current request lifecycle—including no persistence across HTTP requests, queued jobs, or tests with multiple requests. Don’t use it for cross-request sharing (use Cache or Redis instead).
• Keys must be strings: Passing non-string keys (e.g., objects or arrays) silently fails or returns null. Cast to string explicitly if needed.
• No cache tags or TTL: Blink only supports simple key-value storage. If you accidentally reuse a key from a prior computation, it may return stale data—explicitly invalidate with forget() or clear() when needed.

  Blink::forget('user_'.$userId); // or
  Blink::clear(); // wipe entire store mid-request (e.g., after a state-changing action)
  

• Debugging tip: Blink::keys() returns all stored keys; Blink::getMany() fetches multiple at once. Use in tinker or dd(Blink::get('key')) for quick inspection.
• Override with Blink::put(): Unlike Laravel’s Cache facade, put() overwrites existing values without auto-expiry—even if the same key is re-computed. Always use remember() for safe memoization unless you explicitly want to force an update.
• Tests: Since Blink lives in container-scoped memory, be aware it can retain data across test methods in feature tests if not reset. Use Blink::clear() in setUp() or tearDown() when tests mutate Blink state.