Framework Laravel Package

Product Decisions This Supports

• API-first vs. code-first architecture: PSX is built around contract-driven REST APIs (OpenAPI/JSON Schema as the source of truth). Adopting this package is effectively a decision to standardize on spec-first API design in PHP, which shapes how your team writes, reviews, and versions endpoints.
• Build vs. buy for your API layer: If your roadmap includes standing up internal PHP microservices or a public REST surface, this is a candidate to avoid building scaffolding in-house — routing, dispatching, schema validation, and OpenAPI generation come as a cohesive engine.
• Standardizing on a framework engine: Choosing psx/framework (rather than a roll-your-own core) sets conventions for controllers, DI, middleware, and documentation that constrain future feature work and hiring.
• Client-facing contract stability: Because it emphasizes schema-driven endpoints, it supports decisions around generating client SDKs, publishing versioned API docs, and reducing integration support load — a real product-cost lever if you ship an API to partners.
• Roadmap scoping for API surface area: The cost of adding a new endpoint, validating payloads, and documenting it becomes predictable, which informs how aggressively you can expand your public API roadmap.
• Not a Laravel decision: Despite the "Laravel/PHP" framing, this is a standalone PHP framework engine, not a Laravel package. It only supports decisions where you're free to pick the PHP stack — it is not an add-on to an existing Laravel app.

When to Consider This Package

Adopt it when:

• You run (or are evaluating) the PSX framework itself — this is the engine, so it's mandatory, not optional, in that stack.
• You need an OpenAPI-first PHP REST framework with a small, Apache-2.0-licensed dependency footprint and no vendor lock-in on licensing.
• Your team values spec-first API design and schema validation over batteries-included scaffolding.
• You're comfortable with a narrow ecosystem and can absorb maintenance and upgrade risk in-house.

Look elsewhere when:

• Ecosystem risk is a blocker: 8 stars and 0 dependents means effectively no community, no Stack Overflow corpus, no third-party ecosystem, and a very thin hiring pool. This is a single-maintainer-scale risk.
• You're already on Laravel or Symfony: use Laravel's API resources/validation or Symfony's API Platform — dramatically larger talent pools, documentation, and long-term support.
• You need LTS or commercial support guarantees: nothing here provides that; treat maintenance as an internal ownership commitment.
• You need a well-trodden upgrade path: low adoption means fewer real-world upgrade reports and fewer people who've debugged the edge cases you'll hit.
• You're building a platform bet: for a core, long-lived product surface, the adoption and longevity signals (score 0.22, minimal dependents) argue against making this foundational.

How to Pitch It (Stakeholders)

To executives: This is a lightweight, Apache-2.0-licensed engine for building contract-driven REST APIs in PHP. It has real upside — spec-first design cuts integration and documentation waste and makes API expansion cheaper per endpoint — but the strategic picture is caution: near-zero adoption, no dependents, and a very small maintainer base mean we own the maintenance risk and can't hire for it easily. Frame it as a fit for a bounded internal or prototype API, not as the foundation of a customer-facing platform, unless we're prepared to fork and staff it.

To engineering: PSX gives you OpenAPI/JSON Schema as the contract, with routing, validation, and documentation in one engine. It's not Laravel and not Symfony — adopting it is a stack commitment. Before we commit, we need an explicit answer on: who owns upgrades, how we handle upstream stagnation, and how we'd onboard new engineers with almost no community documentation. If the team is already in PSX, this is the core and the conversation is moot; if not, benchmark it against API Platform and Laravel before deciding.