Think Multi App Laravel Package

Technical Evaluation

Architecture fit — The package is a ThinkPHP 6 framework extension, not a Laravel package. It restores the ThinkPHP 5 “multi-app” model that was removed from the TP6 core: requests resolve to app/{appName}/… via a MultiApp middleware plus a framework service, with either first-path-segment routing or domain binding. It plugs into the HTTP kernel through the framework’s native service/middleware registration, so there are no hacks or monkey-patches. The trade-off is blast radius: it changes the directory layout and routing resolution for the entire application. It is an all-or-nothing structural decision, not a composable library you can adopt incrementally inside part of the codebase.

Integration feasibility — High on ThinkPHP 6/8, effectively zero on Laravel. Adoption is composer require, register the service, add the middleware globally, restructure app/, define app_map/domain_bind, set a default app. On TP6 that is roughly half a day for a small codebase and a week for a large route surface. On Laravel this should be rejected at stack fit; the equivalents are native route groups/domain routing or nwidart/laravel-modules.

Technical risk — Moderate overall, with the risk concentrated in adoption rather than code quality. It is first-party (top-think org), Apache-2.0, and released 2024-11-25, so it is maintained but thinly. 20 stars and 0 listed dependents means essentially no third-party validation, no Q&A corpus, and Chinese-first documentation. Specific risks: coupling to framework internals across the 6.0 → 6.1 → 8.0 line; partial and often surprising per-app isolation of config, cache, session, and language files; route-cache invalidation when apps are added; ambient resolved-app state under Swoole/Workerman-style runtimes; and app-name handling if it is ever derived from user input.

Key questions — Which ThinkPHP major/minor is actually supported, and is 8.x officially in scope? Is path-based routing or domain binding our intended model? Does per-app config/cache/session isolation meet our isolation requirements, or is this purely URL segmentation? What is the behavior on an unknown app name — 404, exception, or silent fallback to default? Is it safe under a persistent-worker runtime? What is our contingency if top-think stops releasing, given the code is small enough to vendor and fork?

Integration Approach

Stack fit — This is the decisive gate. ThinkPHP 6/8 only; confirm the framework version before any estimation is done. A Laravel estate should stop here and use native route groups.

Migration path — Two distinct shapes. From TP5.x’s module layout, this is essentially a compatibility shim: move module directories under app/, preserve namespaces, register the middleware, and map the old module names — mostly mechanical, low effort. From a single-app TP6 codebase it is harder: controllers, models, and views move into app/{name}/; per-app route files replace the single route/app.php; global middleware must be triaged into global versus per-app; and genuinely shared code should be hoisted into a common namespace rather than duplicated into every app.

Compatibility — Pin the composer constraint to the exact framework minor. Validate against existing middleware, route rules, and any package that assumes a single app namespace — auth guards, admin panels, and queue jobs that resolve classes by name are the usual casualties.

Sequencing — Prove it in a spike branch with two apps and one shared service. Inventory routes and controllers, then define app boundaries along deployment and ownership lines rather than technical layers. Migrate the smallest app first and serve it on a hostname while the legacy single-app entry point remains live. Add apps one at a time; retire the old entry point last. Keep public/index.php switchable so rollback is a configuration change rather than a revert.

Operational Impact

Maintenance — The surface is small (a middleware, a service, an app resolver), so budget a few hours per framework upgrade. Pin versions in composer.lock and read the ThinkPHP changelog before bumping. The realistic risk is not bug volume but abandonment: with 20 stars and no dependents there is no community patch pressure, so plan to vendor the source into the repo if releases go quiet. It is small enough that forking is cheap insurance.

Support — First-party but with Chinese-language documentation and community channels; no commercial backing. Expect internal ownership, and nominate one engineer as the recognized expert rather than assuming external help is available.

Scaling — Routing overhead is negligible and scales with the number of apps, not with traffic. Isolation is logical, not physical: apps share the process, the config loader, and often the cache and session backends, so noisy-neighbour problems are configuration problems here. Horizontal scaling is unaffected. Under persistent-worker runtimes (Swoole, FrankenPHP worker mode), explicitly verify that resolved-app state is reset per request.

Failure modes — Wrong-app resolution from a misconfigured app_map or domain_bind, which is silent and severe because traffic is served by the wrong application; stale route cache after adding or renaming an app; ambiguous unknown-app behavior; per-app config bleed where one app’s environment overrides another’s; middleware registered globally that should be per-app; autoload or class collisions when shared code is copy-pasted into each app instead of hoisted; and path traversal if app names come from user input without validation.

Ramp-up — A ThinkPHP-fluent engineer is productive in under a day; a Laravel-only team should not attempt it. The durable artifact is a one-page convention doc covering app boundaries, where shared code lives, the routing resolution order, and the checklist for adding an app including cache clear. That document, more than the package, is what keeps the structure from eroding — and given the thin ecosystem around it, treat the package as a small, forkable internal dependency with a named owner rather than as an external library you are betting on.