Salvager Laravel Package

Technical Evaluation

Architecture fit

• Salvager is a thin Laravel wrapper around Playwright, positioning it as a "crawler" rather than a general browser-automation framework. That is the right shape for Laravel: a facade/service binding plus, most likely, an artisan command and a job-friendly entry point.
• The genuine architectural value is that it brings JS-rendered DOM access into the Laravel container. Existing first-party options (HTTP client, Goutte) cannot execute JavaScript; Symfony Panther is the closest incumbent but is WebDriver-based and heavier to reason about. If the use case involves SPAs, lazy-loaded content, or login flows, Playwright is the technically superior engine.
• Fit is strongest as an isolated ingestion component — one queued job class that calls the crawler and hands HTML/artifacts to a pipeline. It is a poor fit as an inline, request-path dependency.
• The critical architectural fact is that this is a PHP↔Node bridge. Playwright is a Node library; any PHP client is a protocol shim. That introduces a second runtime into the application's deployment topology, which is an architectural decision, not a library choice.

Integration feasibility

• Integration mechanics are trivial: Composer install, config publish, and a npx playwright install / browser-binary provisioning step. Surface area is small, so a spike should reach "hello world scrape" in well under a day.
• The real work is environment provisioning: Node 18+, Chromium system libraries (libnss3, libatk, fonts), and a matching Playwright browser build. That means a custom base image or a sidecar container — a platform-team conversation, not a composer require.
• Compatibility must be pinned deliberately: the PHP driver version, the Playwright npm version, and the downloaded browser revision move in lockstep. Unpinned, this breaks silently on rebuild.

Technical risk

• Adoption risk is the dominant risk. 7 stars, 0 dependents, and a composite score of 0.125 mean effectively zero production vetting. There is no downstream evidence that this survives real traffic, and no signal of a maintenance commitment.
• Single-maintainer / abandonment risk is high. With MIT licensing we can fork, but that converts a dependency into an owned artifact.
• Bridge fragility: any change in Playwright's protocol or CLI surface can break the PHP shim, and the fix lands upstream on someone else's schedule.
• Capability gaps are likely in the areas that matter operationally: concurrency/pooling, proxy rotation, session and cookie persistence, robots.txt/politeness, retry/backoff, and structured extraction. A "tiny" crawler probably assumes you supply those.
• Compliance risk is under-owned: crawling carries ToS, rate-limit, and data-handling obligations that no package can discharge for you.

Key questions

• Which PHP Playwright client does it depend on, and is that dependency the fragile link?
• How is the browser process lifecycle managed — spawned per call, reused, or pooled? What is the per-call latency and memory floor?
• Does it return raw HTML only, or support screenshots, PDFs, headers, cookies, waits/selectors, and timeouts?
• Is concurrency supported, or is it strictly sequential per process?
• What are the supported Laravel/PHP versions, and is there CI with a real browser?
• Is there a commit history active in the last 6–12 months, and tagged releases?
• Does it integrate with the queue (retryable jobs) or is it a synchronous call only?

Integration Approach

Stack fit

• Fits cleanly into a standard Laravel 10/11 stack if the app already runs queues (Horizon/Redis) and object storage for artifacts. The crawler belongs in a dedicated queue and a dedicated worker pool, not on the web dynos.
• Natural composition: Job → Salvager → HTML/artifact → parser → domain model. Keep Playwright entirely behind an application-owned interface so the engine is swappable.

Migration path

• Do not adopt as a greenfield dependency on the critical path. Run it behind an internal PageFetcher/Renderer contract with two implementations: the existing HTTP/Goutte path and the Salvager/Playwright path. Route by site capability (JS-required vs static).
• If Panther is already in place, treat Salvager as a like-for-like replacement candidate for specific slow or flaky targets, not a wholesale swap. Benchmark both on the same three URLs before deciding.
• If nothing exists, the migration is simply "add one job" — the lowest-risk possible entry point.

Compatibility

• Build a crawler-specific container image pinning PHP, Node, Playwright, and browser revision; do not rely on the app image.
• Verify behavior against PHP 8.2/8.3 and the target Laravel major in the spike, since low-adoption packages often lag framework releases.
• Confirm it plays nicely with Http fakes / test doubles; if not, wrap it so tests never launch a browser.

Sequencing

1. Spike (2–3 days): one target URL, measure latency, memory, and reliability over ~100 runs.
2. Wrap: define the internal contract, add a fake for the test suite.
3. Pilot: one production use case on a dedicated queue with timeouts and circuit breaking.
4. Observe: success rate, p95 duration, memory per worker, failure taxonomy.
5. Scale or revert: only expand after the pilot proves a stable failure budget. Keep the static-HTTP path as fallback throughout.

Operational Impact

Maintenance

• Assume you will own this code. Budget for periodic patching when Playwright releases break the bridge, plus framework-upgrade drift. Realistically a few days per year, spiking on a Playwright major.
• Vendor it deliberately: fork to an internal namespace, or at minimum pin the exact version and mirror the browser binary in your own artifact store. Never depend on a live playwright install at deploy time.

Support

• Community-only, no SLA, no vendor to escalate to. Internal ownership must be named before adoption — a specific engineer or team accountable for upgrades.
• Documentation is likely thin; expect to read the source. Acceptable for a small wrapper; unacceptable for anything touching revenue.

Scaling

• Cost model is memory-bound, not CPU-bound. Headless Chromium runs roughly 200–500 MB per instance; concurrency is governed by RAM, not worker count. Size the crawler pool independently of the general queue.
• Scale horizontally with more worker containers rather than more concurrent pages per container, until memory pressure is measured.
• Add your own rate limiting and per-domain politeness — Playwright will happily saturate a target and get you blocked. This is application responsibility, not package responsibility.
• Artifact storage (screenshots, HTML) grows fast; set retention and lifecycle rules from day one.

Failure modes

• Node process orphaned or crashed mid-navigation, leaving the PHP call hanging — needs hard timeouts and kill-on-timeout.
• Browser binary missing or version-mismatched after image rebuild — fails at runtime, not build time, unless you smoke-test.
• Slow/hung page, infinite scroll, or anti-bot challenge (Cloudflare) returning a 200 with a block page — silent data corruption, not an error.
• Memory creep across long-lived workers — prefer recycling workers after N jobs.
• Target site changes markup, breaking extractors; and legal/ToS exposure if politeness controls are absent.
• Queue backpressure: a slow crawler starves other jobs unless it has a dedicated queue and worker pool.

Ramp-up

• API learning curve is negligible — a competent Laravel engineer is productive in hours.
• Operational ramp-up is the real cost: headless browser debugging, container provisioning, and memory profiling. Estimate one to two weeks for an engineer new to Playwright-in-production; prior Dusk or Panther experience cuts this substantially.
• Mitigate by having the pilot owner write a short runbook covering browser provisioning, timeout tuning, and the top five failure signatures.

Bottom line for a TPM: the opportunity score (23.35) reflects a real, recurring need — JS-capable crawling inside Laravel — that first-party tooling does not serve well. The maturity score (0.125) reflects that this specific package is unvetted and single-maintainer. Recommendation: conditional pilot only, isolated behind an internal interface, off the critical path, with a named owner and a documented fallback to static HTTP fetching. Do not make it a platform-wide standard, and do not adopt without the spike and the container-provisioning plan.