Api Platform Ms Bundle Laravel Package

Technical Evaluation

What changed in v1.2.0: a single dependency-compatibility change — Signify support for API Platform ^4.0 and Symfony ^7.0 (PR #90). No new features, no API surface changes, no documented deprecations. This is a maintenance release that keeps the bundle aligned with the two current upstream majors.

Architecture fit: Poor for a Laravel-first estate. Despite the "Laravel/PHP package" framing, this is a Symfony bundle (mtarld/api-platform-ms-bundle) built on API Platform's bundle/DI conventions. There is no Laravel service provider, no config/*.php publishable config, and no Illuminate surface. It is only directly consumable by Symfony applications that already run API Platform. In a Laravel codebase the realistic adoption unit is the underlying Signify signing library, not this bundle — and even then only if we are standardising HTTP message signing between services.

Technical risk (ranked):

1. Ecosystem lock, not framework lock. Adopting the bundle ties us to API Platform's release cadence, which is moving fast (v4 is a major). We would be tracking two upstream majors instead of one.
2. Constraint ambiguity. The notes say "support for ^4.0 and ^7.0" without stating whether ^3.x / Symfony ^6.4 constraints were retained. Read as an addition, it is a safe widening; read as a replacement, it is a de-facto breaking change shipped under a minor version. This must be confirmed from composer.json before any pin.
3. Project maturity / bus factor. Small, low-activity, effectively single-maintainer project. No prior assessment exists in our records, so there is no internal track record to lean on.
4. Transitive weight. Pulls API Platform plus Signify plus their constraints — non-trivial for what is a thin signing integration.

Key questions:

• Does v1.2.0 add API Platform 4 / Symfony 7 alongside 3.x / 6.4, or replace them? What is the resulting support matrix and PHP floor (Symfony 7 implies PHP 8.2+)?
• Which services, if any, in our estate are Symfony/API Platform today? If none, this is an out-of-scope package.
• What exactly does Signify cover — request signing/verification only, or key lifecycle (publication, rotation, revocation)?
• Is there a security review or CVE history for Signify and its crypto dependencies?
• Who owns upgrades internally, and what is our policy on single-maintainer dependencies for auth-adjacent code?

Integration Approach

Stack fit: Not a Laravel integration. Treat it as a Symfony-only component. If our platform is Laravel, the correct decision is do not integrate the bundle; evaluate Signify standalone only if we have a cross-service signing requirement, and expect to write the Laravel middleware ourselves (a service provider, a config file, and a verification middleware — roughly a few days of work, none of it provided by this package).

Migration path: If any Symfony 6.4 / API Platform 3 service exists, v1.2.0 is the intended upgrade target for the forthcoming Symfony 7 move. Sequence the framework upgrade first, then this bundle — not the reverse. Where a service is pinned to API Platform 3.x, verify the retained constraint before bumping; if the old constraints were dropped, stay on v1.1.0 and plan the upgrade as a coordinated change.

Compatibility checks before adoption:

• composer why-not against the target app to confirm PHP/Symfony/API Platform resolution.
• Lockfile diff review — a minor bump that shifts a major upstream's constraints can move many transitive packages.
• Confirm the bundle's test matrix covers the Symfony 7 / API Platform 4 combination, not just that a constraint was widened.

Sequencing:

1. Confirm scope: is there any Symfony/API Platform service in the estate? If no, close the evaluation.
2. If yes, pilot in one non-critical internal service, with signing enabled in observe/log-only mode before enforce.
3. Validate key distribution and rotation against our secrets management.
4. Roll per-service, gated on zero signature-verification errors in the pilot for a defined soak period.

Operational Impact

Maintenance: Low code surface, Composer-managed, so routine upkeep is small. The real cost is cadence-tracking: every API Platform major (roughly annual) forces a dependency review, and we have no upstream influence. Budget a named owner and a recurring review slot rather than an ad-hoc "bump when it breaks" habit.

Support: Community-only, no vendor SLA, no commercial backing. For anything in the request-authentication path this is the dominant risk — a signing bug is an outage, not a bug. Compensate with an internal fork-or-pin policy and a documented rollback to the last known-good version.

Scaling: The bundle is not the bottleneck; key distribution is. Signing adds per-request CPU overhead (asymmetric crypto is not free — measure it on the p99 path before enforcing). Verification cost multiplies with call fan-out in a microservice mesh. Key publication/rotation is the operationally expensive part, and this release says nothing about it.

Failure modes to plan for:

• Signature verification failures from clock skew — mandate NTP and a tolerance window.
• Key rotation gaps: rotation without overlapping validity causes cluster-wide 401s.
• Misconfiguration that silently disables verification (fail-open) — require an explicit enforced-mode assertion and an alert on unverified traffic.
• Major-version drift: an API Platform 5 release orphans the bundle until the maintainer ships another compatibility PR; our upgrade timeline becomes someone else's.
• Single-maintainer abandonment — no successor path.

Ramp-up: Small. The bundle's configuration is conventional Symfony. The real ramp-up cost is team familiarity with Symfony bundle/DI conventions if we are a Laravel shop, plus the domain knowledge of signing/key lifecycle. Estimate one to two days to integrate in a Symfony service already on API Platform; a week or more if we are building the equivalent behaviour ourselves in Laravel, which is the likely outcome.

Recommendation: No action on the basis of v1.2.0 alone. It is a routine compatibility release for a package that does not fit a Laravel stack. Re-open only if (a) we onboard Symfony 7 / API Platform 4 services, or (b) we adopt Signify as a cross-service signing standard — in which case confirm the API Platform 3.x constraint retention and the Signify key-lifecycle story first.