Framework Laravel Package

Technical Evaluation

Architecture fit — fundamentally mismatched. psx/framework is not a Laravel package; it is the kernel of a competing full-stack PHP framework (PSX). It ships its own DI container, HTTP kernel, router, and configuration layer rather than binding to Laravel's service container, facade, or package-discovery conventions. There is no ServiceProvider, no Laravel contract implementations, and no expectation of operating inside a Laravel request lifecycle. Any plan that assumes composer require psx/framework alongside laravel/framework and a few lines of wiring is not achievable — the two would collide over kernel and container ownership.

Integration feasibility — viable only as a separate service. The realistic option is running PSX as an independent PHP application (own vhost / container / reverse-proxy mount) and treating it as an HTTP boundary, not a library. That is a large architectural commitment for what the score (0.22) and adoption signals suggest is a marginal dependency.

Technical risk — elevated.

• Adoption: 8 stars, 0 dependents. Effectively no third-party production footprint to borrow operational learnings from.
• Bus factor: apioo is a single-maintainer organisation; continuity depends on one author.
• Ecosystem gravity: Laravel's first-party packages (Sanctum, Horizon, Telescope, Pulse, Octane) have no PSX equivalents, so we would rebuild or forgo them.
• Mitigating factors: Apache-2.0 is commercially safe, and the sibling components (psx/api, psx/openapi, psx/schema) are PSR-oriented and genuinely strong at OpenAPI-first API generation — the one capability worth evaluating on its own merits.

Key questions for the spike:

1. What is the actual requirement — an OpenAPI-first API layer, or a Laravel replacement? If the former, can psx/openapi be used as a dev-time codegen tool outside the framework kernel?
2. Which PHP versions are supported, and what is the release cadence / security-patch history over the last 24 months?
3. Do we already run any PSX in production, or is this greenfield evaluation?
4. Is the team willing to own two DI containers, two config systems, and two upgrade cadences indefinitely?

Integration Approach

Stack fit — poor for a Laravel monolith, narrow for a polyglot edge. If our stack is Laravel-centric, PSX fits nowhere: it cannot decorate Eloquent, queues, broadcasting, or Blade. If we maintain a service-oriented estate where each API can pick its own framework, PSX could occupy an isolated, spec-driven API service — but that is a strategic platform decision, not a package adoption.

Migration path — none incremental. There is no progressive-adoption story. The only workable shape is a strangler pattern at the network edge: stand up a PSX application as a separate deployment, route a bounded set of routes to it via nginx/ALB path rules, and leave Laravel serving everything else. Shared auth would need to be re-established (JWT or an introspection call), since Laravel's session/guard stack does not cross the boundary.

Compatibility. Composer-installable and PSR-aligned, so it will coexist in the same monorepo and CI image. Runtime coexistence in one process is the non-starter; deployment-level coexistence is fine. Expect PHP minor-version constraints to lag Laravel's by design.

Sequencing.

1. Week 1 — requirement triage. Confirm whether the real need is OpenAPI generation. If yes, evaluate psx/openapi as a standalone dev dependency in the Laravel build; this is the highest-value, lowest-risk extraction.
2. Week 2 — isolated spike. One non-critical, read-only API surface rebuilt in PSX in a scratch repo. Measure time-to-first-endpoint, test ergonomics, and observability gaps.
3. Week 3 — go/no-go. Gate on: maintainer responsiveness, documented upgrade path, and whether the spike beat Laravel + dedoc/scramble or knuckleswtf/scribe on effort.
4. Only if green: pilot one production service behind the edge proxy, with a documented exit ramp.

Recommend against any path that touches core customer-facing APIs before step 4 clears.

Operational Impact

Maintenance. Two framework upgrade tracks, two dependency trees, two security-patch feeds. Given a single-maintainer upstream, we should assume we may need to fork and patch — budget for that explicitly or accept the risk in writing.

Support. No commercial backing, no SLA, small community. Incident triage falls entirely to our team; there is no vendor escalation and thin public corpus to search. Compare against Laravel's paid support options and dense community answers.

Scaling. PSX is stateless PHP and scales the same way as any PHP-FPM application — horizontal replicas behind a load balancer. The cost is operational rather than computational: we would duplicate our Laravel-shaped tooling for config, secrets, logging, tracing, and health checks, doubling the surface our platform team must keep consistent.

Failure modes.

• Abandonment: upstream goes quiet; PHP minor upgrades eventually break the kernel and we inherit a fork.
• Boundary drift: shared auth/validation logic reimplemented on both sides, diverging silently.
• Duplicated observability: gaps in tracing across the proxy seam make latency and error attribution slow during incidents.
• Skill concentration: one or two engineers become the only people who can safely change the PSX service.

Ramp-up. Expect meaningful onboarding cost. PSX documentation is thin relative to Laravel, idioms differ (its DI and routing conventions are its own), and engineers cannot transfer Laravel intuition. Realistically 2–3 weeks before a mid-level engineer is productive, versus days for a well-supported Laravel package.

Bottom line. Score 0.22 with 8 stars and 0 dependents is a fair verdict for framework adoption, and the Laravel-integration premise does not hold at all. The defensible move is to extract the OpenAPI-generation capability, if that is the underlying need, and decline the framework itself.