Installer Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM has to correct in the brief: api-platform/installer is not a Laravel package. API Platform is a Symfony-based framework for building hypermedia/HATEOAS, REST, and GraphQL APIs, and this package is a Composer project template (composer create-project) that scaffolds a full Symfony application pre-wired with API Platform, Doctrine, Docker Compose, Caddy/FrankenPHP, and Postgres. It is a bootstrap artifact, not a runtime library. Fit is therefore binary: strong on a greenfield Symfony service, near-zero inside an existing Laravel codebase. There is no service provider, no facade, no Eloquent bridge, and no reason to expect one.

Integration feasibility. As a standalone bounded-context service behind an API gateway, feasibility is high — the template gets a team to a running, OpenAPI-documented endpoint in hours. As an in-process dependency of a Laravel app, feasibility is effectively zero; the only shared substrate is the PHP runtime, Composer, and PSR interfaces (PSR-7/15/18) for cross-cutting libraries. Treat any attempt to "install it into" a Laravel app as an anti-pattern.

Technical risk.

• Template, not dependency. Once generated, the scaffold is ours. Upstream refinements do not flow to us; the Docker/Caddy/PHP-FPM configuration will drift from org platform baseline and must be rewritten for our orchestrator anyway.
• Framework churn. API Platform major versions have historically carried meaningful breaking changes to resource metadata, serialization groups, and filter syntax. Budget for an upgrade cycle roughly annually.
• Dual-framework surface. Running Symfony and Laravel side by side doubles the operational and cognitive footprint: two DI models, two ORM philosophies (Doctrine vs Eloquent), two caching stories, two upgrade calendars.
• Metadata quality of this evaluation. Dependents: 0 is expected for a project template and not a red flag, but it means the opportunity score of 0.94 is popularity-driven, not adoption-driven. The Last release: 2026-06-14 date is in the future and should be treated as a data-quality defect until verified. The repo URL points at the umbrella API Platform repository, not obviously at the installer package — confirm the actual package identity before any commitment.
• Licensing. MIT, clean. No copyleft exposure.

Key questions.

1. Which artifact is actually being proposed — the api-platform/api-platform distribution, or the installer package, and who maintains it in lockstep with api-platform/core?
2. What is the supported PHP and Symfony version matrix, and does it match our runtime standard?
3. Is the intent a new bounded-context API service, or a replacement for an existing Laravel API layer? The answer changes the risk profile by an order of magnitude.
4. Who owns framework upgrades after generation — the platform team or the consuming product team?
5. Does the scaffold's infrastructure opinionation (Caddy, FrankenPHP, Postgres, Mercure) match our platform baseline, or is it throwaway?
6. What is the exit cost if we abandon it in 18 months — is the API contract (OpenAPI) portable enough to re-implement behind the same gateway?

Integration Approach

Stack fit. Reuse is limited to the PHP runtime, Composer, PSR interfaces, and whatever observability/HTTP-client libraries are PSR-compliant. Everything else — routing, validation, ORM, migrations, queue workers, auth middleware — is a parallel implementation. If the platform standard is Laravel + MySQL + Nginx, assume ~0% code reuse and ~100% conceptual duplication.

Migration path. Only one path is defensible: stand it up as a new, separately deployed service owning a single bounded context, fronted by the existing API gateway. Share identity via OIDC/JWT so tokens minted by the Laravel side are validated by the Symfony side; do not attempt shared sessions or a shared database schema. Keep the boundary at the HTTP contract so the service remains replaceable. Migrating existing Laravel endpoints into it should be justified per-endpoint by a concrete driver (GraphQL, hypermedia, JSON-LD, or heavy schema-first API surface), not by framework preference.

Compatibility. Verify PHP minor version against the template's composer.json constraints, required extensions (intl, pdo_pgsql, apcu/opcache), Doctrine DBAL/ORM versions, and Postgres major version. Confirm the generated OpenAPI spec can be consumed by our existing client-generation and contract-testing pipeline; if not, that is a gating issue, not a nice-to-have. Cross-service concerns such as tracing, structured logging, and health/readiness probes will need bespoke wiring — the template ships dev-grade defaults.

Sequencing.

1. Spike (1 week). Generate the project in a sandbox, stand up docker compose, publish one resource, measure time-to-first-authenticated-endpoint and time-to-OpenAPI-export.
2. Parity comparison (1–2 weeks). Implement the same three representative endpoints (a paginated collection with filters, a nested resource, a write with validation) in both API Platform and our Laravel baseline. Score on lines of code, contract fidelity, test ergonomics, and debuggability.
3. Boundary decision. Choose a bounded-context sidecar versus no-go. Do not proceed on "evaluate broadly."
4. Infra baseline pass. Replace the scaffold's Compose/Caddy assumptions with our deployment standard before writing product code, not after.
5. Pilot. One non-critical external API surface, instrumented, with the contract published through the gateway.
6. Gate review. Reassess only with pilot data on defect rate, cycle time, and on-call load.

Operational Impact

Maintenance. The generated application becomes a first-class owned service: dependency bumps, framework upgrades, security patches, and Docker base-image refreshes all land on us. The installer's own release cadence is irrelevant post-generation — that is the single most misunderstood property of a project template. Expect meaningful upgrade work on API Platform major versions and Symfony majors, and a smaller but real ongoing tax reconciling our scaffold with evolving platform standards.

Support. Two support surfaces instead of one: Symfony/Doctrine operational knowledge and API Platform's metadata-driven resource model, which is powerful but has non-obvious failure semantics. Vendor support does not exist (MIT, community-only); we are the escalation path. Internal platform tooling — scaffolding generators, CI templates, secret injection, log shippers — needs a Symfony variant maintained in parallel, which is a permanent, quiet cost.

Scaling. Technically sound: stateless PHP-FPM/FrankenPHP workers scale horizontally behind a load balancer; HTTP caching, Vulcain-style preloading, and Mercure cover read-heavy and push scenarios; the DB remains the bottleneck as with any ORM-backed service. No PHP-level scaling concerns beyond opcache/preload tuning and worker sizing. The real scaling constraint is organizational: a second framework idiom dilutes platform leverage.

Failure modes to plan for.

• Doctrine N+1 queries and hydration memory blowups on deep serialization graphs — the canonical API Platform production incident.
• Production cache warmup failures on deploy (metadata/container cache), presenting as instant 500s on a cold node.
• Major-version upgrades silently changing the serialized payload shape, breaking downstream consumers despite a green build.
• Scaffold infra configs (Caddy, FrankenPHP, Compose healthchecks) promoted to production unmodified, then failing under real traffic or TLS termination.
• Developer error from unfamiliarity: mixing Laravel assumptions (mass assignment, facades) into a Symfony codebase, producing subtle security or lifecycle bugs.

Ramp-up. A competent PHP engineer with Laravel experience is productive in 2–3 weeks and genuinely safe — writing correct filters, serialization groups, and custom state processors — in 6–8 weeks. That is a real but bounded cost for one team. It becomes a systemic problem if the org's hiring profile, code review bench, and on-call rotation are all Laravel-shaped, because then every Symfony service is supported by people reading an unfamiliar framework under incident pressure. Make the adoption decision on that organizational question as much as on the technical merit, and require the pilot's on-call data as the deciding input.