Slim Bridge Laravel Package

Technical Evaluation

Architecture fit. php-di/slim-bridge is a thin adapter that wires the PHP-DI PSR-11 container into Slim 4's AppFactory, enabling constructor autowiring for route callables, middleware, and error handlers. The important framing for a Laravel-centric engineering org is that this is not a Laravel package: Laravel already ships an autowiring container with contextual binding, facades, and service providers, so there is no role for this bridge inside a Laravel application. Its fit is confined to the Slim slice of a polyglot fleet — edge/BFF services, webhook receivers, lightweight internal APIs, and small standalone tools where a full Laravel install is disproportionate. If no Slim services exist today, architecture fit is effectively zero and the package should be evaluated only as a contingency for greenfield microservices.

Integration feasibility. Low effort, low surface area. composer require php-di/slim-bridge plus a ContainerBuilder bootstrap and AppFactory::setContainer() is a hours-not-weeks integration for a team that already runs Slim 4. The package is MIT, PSR-11-native, and interops cleanly with PSR-7/PSR-15 middleware. The friction is organizational rather than technical: it introduces a second DI idiom (attribute-based definitions, #[Inject], PHP-DI config arrays) alongside Laravel's provider/contract conventions, which raises the cognitive and review cost for shared platform engineers.

Technical risk. The code risk is low — small, stable glue, active maintainer ecosystem (PHP-DI under Matthieu Napoli, Slim under the SlimPHP org), and a recent release (2024-11-29). The material risks are: (1) version-matrix drift — the bridge is Slim 4-only and tracks PHP-DI 7.x, so a Slim 5 or PHP-DI 8 release creates a compatibility lag window; (2) bus factor and vendor concentration — no commercial support, single-maintainer-adjacent upstream, so we own the fork risk; (3) container-misconfiguration blast radius — autowiring failures surface as runtime resolution exceptions rather than boot-time failures, which is harder to catch in CI without explicit container-compile smoke tests; and (4) strategic mismatch — the low opportunity score (1.52) against a modest 3.2 composite suggests a commoditized glue package in a niche segment. Treat it as tactical plumbing, not a platform investment.

Key questions.

• Do we actually operate Slim 4 services, or is this being proposed as a "lighter Laravel" alternative? If the latter, reject — the org's leverage is in Laravel conventions.
• Who owns container configuration as a shared standard, and will it be templated across Slim services or re-invented per repo?
• What is our supported PHP / Slim / PHP-DI version matrix, and who watches upstream for Slim 5 readiness?
• Are we prepared to vendor-fork if upstream stalls?
• Does the package's attribute-driven definition style conflict with existing static-analysis or code-review standards?

Integration Approach

Stack fit. Treat the bridge as the DI seam for a separate Slim service tier, not as anything that touches the Laravel monolith. It composes cleanly with the rest of the PSR stack we'd standardize on for such services: PSR-11 container, PSR-7 HTTP messages, PSR-15 middleware, PSR-3 logging. Laravel remains the system of record and the API boundary; Slim services are deliberately narrow (ingress normalization, third-party webhook handling, latency-sensitive proxying) and should not accrete domain logic that belongs behind the Laravel API.

Migration path. There is no path from Laravel to this package, and we should say so explicitly in the decision record to prevent it being misread as a modernization lever. For legacy Slim 2/3 services, the bridge is not applicable until the service is on Slim 4; sequence as Slim 3 → Slim 4 (framework upgrade, independent work) → adopt the bridge (container cleanup). For greenfield Slim services, adopt the bridge from commit zero — retrofitting DI into hand-rolled service location is materially more expensive than starting with it.

Compatibility. Validate against the concrete matrix before approving: PHP 8.1+ (attributes required for the ergonomic definition style), slim/slim 4.x, php-di/php-di 7.x, psr/container 1.x vs 2.x (PHP-DI 7 supports both, but downstream libraries may pin one). Confirm the service does not also register a competing container, and that AppFactory::setContainer() is called before route registration. Add composer audit and a Renovate/Dependabot rule scoped to php-di/* and slim/*.

Sequencing.

1. Inventory: enumerate Slim services in the fleet and their current DI posture (manual wiring, Pimple, service locator).
2. Pilot: convert one low-blast-radius service (internal API or webhook receiver), measure container compile time and cold-start.
3. Standardize: publish a reference bootstrap (compiled container in prod, Development mode only in local/test) and a lint rule banning $container->get() inside business logic.
4. Enforce: CI step that compiles the container in prod mode to fail fast on unresolvable dependencies.
5. Watch: track Slim 5 and PHP-DI 8 roadmaps; schedule a re-evaluation rather than an automatic upgrade.

Operational Impact

Maintenance. Ongoing cost is low but non-zero: pinned versions, periodic upstream review, and ownership of the reference bootstrap. Because the package is glue, most maintenance burden shifts to the services using it (container config hygiene) rather than the dependency itself. Budget a small recurring allocation for dependency review rather than dedicated headcount.

Support. No commercial support and no SLA. Internal ownership must be explicit — a named team accountable for the reference implementation and for adjudicating "should this be a Slim service or a Laravel route?" escalations. Community support via GitHub issues and StackOverflow is adequate for a package of this size, but it is not a substitute for an internal owner.

Scaling. PHP-DI's compiled container removes reflection overhead at runtime and is the correct production default; leaving the container in development mode is the single most common scaling foot-gun here. For high-RPS edge services, benchmark cold-start and per-request resolution on the target runtime (PHP-FPM is the norm; long-running workers need explicit scrutiny of singleton state). Autowiring cost is paid once at compile, so horizontal scaling is not a concern; container rebuilds on deploy are.

Failure modes.

• Runtime resolution errors — missing or ambiguous constructor dependencies that only appear on the first request to an affected route. Mitigation: compile-container CI gate.
• Circular dependencies — autowiring makes cycles easy to introduce and hard to read; fail the build on container compile.
• Service-locator creep — developers calling $container->get() inside domain code, destroying testability and hiding dependencies. Mitigation: static-analysis rule.
• Singleton state leakage — under any long-running runtime, mutable services held as singletons bleed across requests.
• Upgrade-lag breakage — Slim or PHP-DI major bumps before the bridge catches up, stranding services on unsupported versions.
• Convention divergence — Slim services drifting from Laravel idioms, increasing onboarding and cross-team review cost.

Ramp-up. Engineers with Laravel DI experience transfer the concepts (autowiring, bindings, interfaces-to-implementations) in roughly a day; the delta is PHP-DI's attribute-based definitions and array config style, which are unfamiliar and easy to misuse without examples. Budget one to two days per engineer for a first Slim service, plus a short internal write-up. The larger ramp-up cost is organizational: establishing when a Slim service is warranted at all, and resisting the temptation to use this package as a backdoor to a second PHP framework stack.