Rest Bundle Laravel Package

Product Decisions This Supports

• Modular monolith vs. microservices. The package encodes a bet that service-like boundaries — per-module routing, independent ownership, per-module versioning — can live inside one Laravel/PHP deployment. Treat it as an input to that architecture decision rather than the driver of it. The abstraction is the interesting artifact; the code is incidental.
• Build vs. buy vs. fork for API scaffolding. If a platform team is about to hand-roll module registration, convention-based route discovery, response envelopes, and centralized error formatting, this is a fork candidate. The decision is cheap and reversible: a one-sprint audit answers it either way.
• Roadmap sequencing of API surface. How much of the roadmap is "expose module X" versus "build the plumbing to expose anything"? A bundle like this earns its keep only if endpoint plumbing is a recurring, cross-squad tax. If you ship three endpoints a quarter, it doesn't.
• Team topology and ownership. Module-scoped packages map cleanly to squad-scoped ownership. This supports (but does not settle) the question of whether teams can ship endpoints without editing a central routes file or waiting on platform review.
• Use cases worth evaluating against: internal admin/back-office APIs, partner integrations needing per-module version pinning, multi-tenant SaaS where modules toggle per tenant, and strangler-style extraction of a legacy API surface one module at a time.
• Decisions this should not be used to support: anything customer-facing with an SLA, anything on a security-sensitive auth path, or any claim of "this is our standard API approach." Zero stars, zero dependents, and no release history mean zero field evidence. It is an idea, not a proven component.

When to Consider This Package

Consider it when:

• You are on Laravel and already think in domain modules (modular monolith, package-per-bounded-context, DDD-lite), so the abstraction costs you nothing conceptually.
• You want convention-based registration of REST endpoints per module and are willing to own the code rather than consume it.
• The team is small, greenfield, and comfortable reading src/ as the specification.
• You have a concrete spike in mind: wire two real modules through it and compare against the service-provider-plus-routes-file approach you would write anyway.

Non-negotiable gates before it touches a real codebase:

• Vendor or fork the source and pin to a commit SHA; do not depend on it live from Packagist.
• Confirm the actual framework target. The -bundle suffix and micro-module vendor namespace suggest Symfony bundle conventions, not a Laravel package — verify whether a framework-agnostic core exists or whether the logic is welded to Symfony's HttpKernel, EventDispatcher, and DI compiler passes.
• Confirm supported PHP/Laravel (or Symfony) versions, route-caching and middleware compatibility, auth/authorization hooks, API versioning, and the error envelope contract.
• Check license and CLA terms — can you fork and redistribute internally?
• Write your own integration tests around module registration and name an internal maintainer.

Look elsewhere when:

• You need OpenAPI/Swagger generation — use dedoc/scramble or darkaonline/l5-swagger.
• You need a mature, audited auth layer — Sanctum or Passport.
• You need GraphQL — Lighthouse.
• Your org requires maintained dependencies, a security response process, or procurement sign-off. Bus factor is 1, there are no dependents, and there is no disclosure channel.
• The "micro module" abstraction is speculative for you. A service provider plus a route file per module delivers roughly 80% of the benefit with zero dependency — apply YAGNI first.

How to Pitch It (Stakeholders)

To executives: this is a low-cost, low-commitment experiment, not a platform bet. The pitch is "a candidate pattern for letting product teams ship API endpoints independently instead of routing everything through one central bottleneck." The cost is a sprint of engineering time — no licence, no vendor contract, no procurement risk, because the code is small and forkable. Be equally explicit about the downside: zero adoption, a single maintainer, no security track record, and a real chance it is a Symfony bundle that does not drop into our Laravel stack. It can only enter as vendored, internally-owned code with our tests around it — never as a critical dependency. One sprint buys a clear go/no-go.

To engineering: treat it as a reference implementation and possible fork source, not a dependency. One time-boxed spike: clone it, read composer.json and src/ before anything else, then wire two real modules through it and measure whether it actually removes the routes/controller/service-provider boilerplate you would otherwise write. If the core turns out to be framework-agnostic and clears our conventions on versioning, middleware, validation, and error envelopes, extract it into an internal package behind a Laravel ServiceProvider with a named owner and contract tests mirroring upstream. If it is Symfony-coupled or the abstraction is thin, steal the naming and structure ideas and write the couple hundred lines in-house. Watch for Symfony compiler-pass assumptions surfacing as opaque boot errors, route-prefix collisions with existing routes, serialization ambiguity against API Resources, and convention-driven silent fallbacks that mask misconfiguration. Either outcome is cheap and reversible — which is precisely why it is worth one sprint to answer.