Framework integration · Laravel
Laravel
Register only the Fight service providers for capabilities your Laravel application selects.
Installation and ownership¶
Install Fight Common with Laravel. The project-laravel starter owns the application bootstrap, provider registration, configuration publication, migrations, workers, and deployment.
Fight Common does not auto-enable every integration. Application code should continue to depend on portable Fight contracts rather than Laravel adapters.
Select capability providers¶
Register only the needed providers under Fight\Common\Adapter\ServiceContainer\Laravel. Available bounded
providers cover messaging, persistence, security, cache, HTTP responses, routing, templating, mail,
broadcasting, file storage, filesystem, HTTP client, process, metrics, and logging.
Provider selection is the activation boundary. Do not create an application provider that registers every Fight provider by default, and do not rely on unrelated package discovery to choose infrastructure policy.
Native and fallback paths¶
Shipped native paths include Queue messaging, transactional UnitOfWork, password hashing and validation, cache, JSend/error responses, URL generation, Blade, mail, broadcasting, and filesystem. Laravel's PSR-3 logger is wired directly.
Native file storage, HTTP client, process, and Pulse metrics remain prototype decisions with the documented Flysystem, Guzzle/PSR-18, Symfony Process, and shared metrics paths available. Select the proven path required by the application; a prototype label is not a stable adapter promise.
Queue and broadcasting¶
MessagingServiceProvider binds the asynchronous Fight ports to LaravelCommandBus and
LaravelEventDispatcher. Jobs transport complete Fight messages and delegate them to neutral synchronous
handlers. Delivery is at least once, so handlers must tolerate duplicate attempts and repeated event fan-out.
BroadcastingServiceProvider selects both LaravelBroadcastPublisher and LaravelPrivatePublisher. The
application owns channel definitions, authorization, broadcaster configuration, queues, retries, failed jobs,
worker supervision, and durable outbox policy.
Application-owned operations¶
Keep database schema, transaction use, cache stores, filesystem disks and path policy, route definitions, HTTP middleware, templates, mail configuration, process limits, schedules, credentials, monitoring, and deployment in the application. Registering a provider proves composition, not production operations readiness.
Use the Messaging, Cache, Routing, and Mail guides for behavior and failures. Use the support matrix for the complete capability state.