Duckphp Laravel Package

Technical Evaluation

Architecture fit

• DuckPHP is a standalone, opinionated full-stack PHP micro-framework, not a Laravel extension. It ships its own application bootstrap (App), extension/hook system, routing, request/response handling, and view layer. There is no service provider, facade, or illuminate/contracts implementation surface to bind against.
• The package's own positioning ("Laravel larva and Smarty is evil") is adversarial to the stack we standardize on. That is a governance signal, not just marketing: upstream is unlikely to invest in Laravel interoperability, and we would be adopting a philosophy as much as a library.
• Realistic fit is therefore narrow: a greenfield, small-blast-radius PHP service where Laravel is not mandated, or reuse of its patterns (non-intrusive bootstrap, extension hooks) as internal design reference. It is not an in-process addition to a Laravel application.

Integration feasibility

• Technically installable: Composer package, MIT, pure PHP, no exotic runtime. The blocker is not installation, it is the integration boundary — the unit of integration is "the framework," not "a feature."
• Viable patterns, in descending order of preference: (1) pattern harvest, zero dependency; (2) separate DuckPHP service behind an HTTP/queue contract with Laravel remaining system of record; (3) greenfield internal tool. Non-viable: dropping it into an existing Laravel app as a package.

Technical risk

• Bus factor of one (author dvaknheo), 136 stars, negligible ecosystem, no commercial backing. Support capacity is effectively "read the source."
• Documentation and issue traffic are likely Chinese-first. That is workable but must be budgeted as an explicit ramp-up and auditability cost, not discovered later.
• No evidence of PSR-3/4/7/11/15 conformance, test coverage, or CI in the supplied metadata. Unverified compatibility with our PHP floor.
• Release metadata shows 2026-10-19, which is inconsistent with a normal cadence and needs to be reconciled against Packagist before we trust any version claim. The composite score (22.6, opportunity 2.66) is consistent with "low strategic value, high diligence burden."

Key questions

• What PHP versions are supported, and does that matrix clear our floor and our upgrade horizon?
• Which PSRs are implemented, and does the package depend on or conflict with any illuminate/* component transitively?
• Is there a documented security disclosure process, and any CVE history?
• Can the DuckPHP App bootstrap coexist in one process with Laravel's container, or is it strictly one-framework-per-process?
• Does any unofficial Laravel bridge or adapter exist, and is it maintained?
• Who besides the single author has commit rights, and what does the test suite actually cover?

Integration Approach

Stack fit

• Marginal at best. In a Laravel-standardized org this is a second framework with a second set of conventions for routing, DI, config, and views — the cost is organizational divergence, not lines of code. Adopt only where a documented constraint (footprint, cold-start, licensing of attention) genuinely rules out Laravel.

Migration path

• There is no automated migration in either direction. Neither side exposes a compatible container, router, ORM, or view compiler.
• If adopted, adopt greenfield behind an interface boundary — an HTTP API or a queue contract — so the service is replaceable at the seam without touching Laravel. Treat DuckPHP as an implementation detail of one deployable, never as a platform.

Compatibility

• Auth and session are the sharp edge. DuckPHP will not read Laravel's encrypted cookies, session driver, or CSRF tokens out of the box. Plan a token-based bridge (signed short-lived JWT, or a shared Redis session with a custom handler on both sides) and own that code ourselves.
• Persistence: expect a separate DB layer, not Eloquent. Define Laravel as schema owner and DuckPHP as a read-mostly consumer to avoid dual-write divergence.
• Shared observability, config, and secrets management will need adapters; assume nothing is inherited.

Sequencing

1. 5–10 day technical spike: PHP version, PSR conformance, a hello-world service, a container/process coexistence check.
2. Due diligence gate: license (clean, MIT), maintainer health, security posture, doc-language feasibility.
3. Pick exactly one low-blast-radius internal service behind the API gateway.
4. Run in parallel with the incumbent, instrumented, with a defined rollback.
5. Generalize only if it demonstrably earns its keep on cost or latency.

• Hard gate: DuckPHP must never own authentication, payments, or PII in the first adoption.

Verdict Recommend pattern harvest, not adoption for the default case. The only path to a "yes" is a specific, documented constraint plus a greenfield bounded service and a named owner willing to fork if upstream goes quiet.

Operational Impact

Maintenance

• Bus factor 1 is the dominant operational risk. Budget for vendoring the dependency and pinning exact versions; treat every upstream upgrade as a code review, not a composer update. MIT makes forking legally clean but does not make it cheap — assume we inherit the framework if the author stops.
• Two framework conventions in one org means duplicated CI templates, linting, and deploy tooling. That is a recurring tax, not a one-time setup cost.

Support

• No vendor, no SLA, no paid tier. Support means reading source and, realistically, translating Chinese-language docs and issues. Fund a written internal runbook and a translated core-docs digest before the first production deploy, or the ramp-up cost lands on whoever is on call.

Scaling

• The "simple and fast" pitch plausibly holds for stateless request/response, but we have no benchmark of our own and the framework is rarely the actual bottleneck. What we would give up is the surrounding scaling surface: no Octane-equivalent, no Horizon, no first-class queue/event ecosystem. Verify the async and long-running-worker story explicitly; assume it is absent until proven otherwise.
• Horizontal scaling of stateless workers should be fine. Anything requiring shared state, background jobs, or websockets pushes work back onto Laravel-side infrastructure, which partly defeats the purpose.

Failure modes

• Silent divergence: a second routing/DI idiom spreads by copy-paste before anyone notices.
• Upgrade dead-end: upstream stalls; we fork; the fork rots because nobody owns it.
• Security patch latency: no coordinated disclosure means we discover issues via reading commits.
• Seam outages: session/auth mismatch between Laravel and DuckPHP breaks login at the boundary — the highest-severity, hardest-to-test failure.
• Dependency conflict if illuminate/* appears transitively, forcing version pinning of the main app.
• Hiring and onboarding friction: no DuckPHP skills in the market; every new engineer is a net cost for weeks.

Ramp-up

• ~1–2 weeks for a competent PHP engineer to reach basic productivity; ~3–4 weeks to production-grade including the auth bridge, observability adapters, and runbook.
• The real number is opportunity cost: none of that learning transfers back to the Laravel ecosystem, and it does not compound for the team the way Laravel investment does.