- What is vxm/laravel-async used for?
- It is a thin convenience layer that exposes an Async facade for running synchronous PHP code, typically closures, off the request path so heavy or latency-bound work does not block the response. Typical uses are intra-request parallelism such as fan-out HTTP calls, parallel cache or database reads, and speculative work. It is not queue-backed: concurrency comes from the Swoole PHP extension and a long-running Swoole worker. That makes it an application-server decision as much as a Composer dependency.
- Do I need the Swoole extension to use vxm/laravel-async?
- Yes. The package's execution model depends on ext-swoole and a long-running Swoole worker to provide coroutine and process concurrency, so it will not function as a plain PHP library. You need the extension installable and permitted in your runtime image, which usually means self-managed containers or Kubernetes. If you cannot load ext-swoole, this package is not a viable option.
- Can I use vxm/laravel-async on PHP-FPM, shared hosting, or Laravel Vapor?
- No, not realistically. Standard PHP-FPM setups, managed platforms, and serverless runtimes like Vapor or Lambda cannot support the long-running Swoole worker the package needs. Adopting it narrows your hosting options to self-managed containers or Kubernetes with the Swoole extension available. Treat it as compatible only with teams already running Swoole or Laravel Octane with the Swoole driver.
- How do I install and configure vxm/laravel-async in a Laravel app?
- Installation is mechanically simple: composer require vxm/laravel-async, publish the package config, and call the Async facade from your code. The real prerequisites are environmental, not code-level: verify ext-swoole is in the base image, confirm the Swoole, PHP, and Laravel version matrix lines up, and make sure the app is served by a long-running worker rather than FPM. Before committing, pin the package version and validate that the code paths you intend to offload are coroutine-safe.
- Which Laravel and PHP versions does vxm/laravel-async support?
- The supported constraint set is not clearly established in the available context, so you must inspect the package's composer.json and its release notes rather than assume. The last release was mid-2024, so compatibility with Laravel 11 and 12 and with PHP 8.3 or 8.4 needs explicit verification. Also confirm whether it tracks Swoole 5.x and 6.x. Validate in this order: extension availability, the Swoole versus PHP versus Laravel matrix, Octane coexistence, then coroutine safety of your target code.
- Is vxm/laravel-async a replacement for Laravel queues?
- No, and you should not rip out your queue system for it. Async work is in-process and has no durability: deploys, restarts, and OOM kills silently drop tasks, and there is no retry, backpressure, or dead-letter semantics comparable to a queue. Queues should remain the system of record for durable, retryable, cross-service work, while this package handles short-lived, loss-tolerant, latency-sensitive fan-out inside a request.
- Is it safe to run Eloquent queries and DB transactions inside an Async closure?
- Coroutine safety is left to the caller, and that is where the real cost of adoption sits. Shared container state, shared PDO connections, and mutable singletons are all hazards under coroutines; a closure touching Eloquent can leak connection state or interleave transactions unless connections are explicitly isolated per coroutine. Avoid DB::transaction spanning coroutines, and test the exact code paths you plan to move. Wrapping the package behind your own interface makes it easier to isolate and swap later.
- Does vxm/laravel-async work with Laravel Octane?
- It fits best with teams already on Octane using the Swoole driver, since both rely on a long-running Swoole worker. Whether it can run inside an Octane worker without conflict is one of the key questions you should validate before committing, not something to assume. Test coexistence in a staging environment with representative coroutine workloads. If conflict appears, an abstraction layer implemented once by this package and once by Laravel's Concurrency facade limits the blast radius.
- What happens if an async task fails or the worker runs out of memory?
- Work is in-process, so a fatal error or memory exhaustion inside a coroutine can take down the worker and every in-flight task with it, not just one job. There is no retry or dead-letter behavior to recover dropped tasks after a restart or deploy. Timeout and exception semantics also need to be tested directly against the package. For anything where failure must be recoverable, use the queue instead.
- Is vxm/laravel-async actively maintained, and what are the alternatives?
- The project has roughly 154 stars, zero dependents, a single primary maintainer, and a last release in mid-2024, so treat it as vendor-your-own-code risk and check for maintained forks. Laravel 11 and later ship first-party Concurrency with process pools, and Octane has matured, which shrinks this package's unique value. The pragmatic approach is to define your own runner interface, such as App\Support\Concurrency\Runner with run, await, and all methods, implemented once by this package and once by Laravel Concurrency or a spatie/async pool. That keeps the runtime bet reversible.