Openswoole Bundle Laravel Package

Getting Started

• Confirm you are in a Symfony app, not Laravel. This is a Symfony bundle (silpo-tech/openswoole-bundle), so it will not install into a Laravel project as a normal Laravel package. Laravel developers should treat it as a reference implementation and use Laravel Octane for OpenSwoole-based serving.
• First inspect the repository files in this order:
  1. README.md for installation and start command.
  2. composer.json for PHP/OpenSwoole/Symfony version constraints.
  3. The bundle class and DependencyInjection/ for configuration keys.
  4. The console command or runtime entry point used to start the OpenSwoole server.
• Minimal Symfony setup:

  composer require silpo-tech/openswoole-bundle
  

  Register the bundle in config/bundles.php, add any required config under config/packages/, then start the worker using the command documented by the bundle.
• First use case: run a Symfony HTTP kernel inside a long-lived OpenSwoole worker instead of PHP-FPM. Validate this on a small, stateless endpoint before moving real traffic.
• For Laravel day-to-day work, the practical first step is different: install Laravel Octane and use its OpenSwoole driver. Use this bundle only if you are maintaining a Symfony service or studying how another team handled OpenSwoole lifecycle integration.

Implementation Patterns

• Symfony-only integration: register the bundle, configure host/port/worker settings, and boot the Symfony kernel per worker. Keep the bundle's config environment-specific and avoid hard-coding production worker counts in source control.
• Long-running request loop: treat each request as occurring inside a worker that has already booted the framework. Services, singletons, static properties, and container state survive between requests unless explicitly reset.
• Service reset discipline: identify stateful services—database connections, Doctrine entity managers, auth/session state, request-scoped services, loggers with request context, and caches—and reset or recreate them per request. In Laravel terms, this is the same discipline Octane requires via listeners and sandboxing.
• Coroutine-safe code: avoid blocking I/O inside request handlers unless the server configuration isolates it. Database, Redis, HTTP, and filesystem clients must be compatible with OpenSwoole coroutines or be wrapped so they do not block the worker.
• Configuration isolation: keep OpenSwoole-specific settings separate from normal Symfony runtime configuration. Use environment variables for worker count, max requests, timeouts, and reload behavior so local development and production differ cleanly.
• Observability integration: log worker ID and request ID in every log line. In a long-running server, missing request context is one of the fastest ways to make debugging painful.
• Graceful restart pattern: configure max-request recycling and support graceful shutdown. Deploy by restarting workers, not by assuming code changes are picked up automatically.
• Laravel equivalent pattern: if you are translating this to Laravel, map the bundle's lifecycle concerns to Octane listeners: warm services at worker boot, flush request state after each request, recycle workers after a request limit, and verify every package is Octane-safe.
• Reference use: if you cannot use the bundle directly, use it to understand the shape of an OpenSwoole Symfony bridge: kernel bootstrapping, request conversion, response emission, worker lifecycle hooks, and container reset points.

Gotchas and Tips

• Not a Laravel package: there is no Laravel service provider, facade, or config/open-swoole.php. Do not try to install it into a Laravel app expecting php artisan integration.
• Very low adoption: 3 stars and 0 dependents means limited community validation. Audit the code and pin a exact version. Expect to own maintenance and upgrades yourself.
• Version constraints: check PHP, Symfony, and OpenSwoole extension compatibility before upgrading any of them. A mismatch often appears as a worker crash, not a clean Composer error.
• Memory leaks are the default failure mode: long-running workers accumulate memory through static caches, Doctrine identity maps, event listeners, and global state. Enable max-request recycling and monitor worker memory.
• Database connections go stale: reconnect or reset connections after failures. Do not assume a connection opened at worker boot is valid hours later.
• Superglobals are unreliable: $_GET, $_POST, $_SERVER, and $_SESSION may not reflect the current request in the way PHP-FPM code expects. Use the framework request object and avoid code that reads globals directly.
• Debugging changes behavior: dump(), dd(), Xdebug, Symfony profiler, and debug toolbars can leak state or break response handling in long-running workers. Reproduce production issues with production-like worker settings.
• Code changes are not automatically loaded: OPcache and already-booted workers can serve old code. Clear Symfony cache and restart workers during development and deployment.
• Streaming and large responses need explicit validation: test file uploads, downloads, streamed responses, SSE, and long-polling against the bundle's request/response conversion. These are common incompatibilities in OpenSwoole bridges.
• Timeouts and worker kills: configure OpenSwoole timeouts and Symfony-level timeouts consistently. A request killed at the server layer may bypass normal exception handling.
• Extension points to inspect: bundle configuration under DependencyInjection/, console commands, event listeners/subscribers, and any service-reset or kernel-lifecycle hooks. Those are the places to add application-specific cleanup, metrics, and health checks.
• Safer Laravel alternative: for day-to-day Laravel work, use Laravel Octane with the OpenSwoole driver and audit packages with composer why-not and Octane compatibility checks. This bundle is best treated as a Symfony-specific reference, not a drop-in Laravel dependency.