Nimbus Laravel Package

Product Decisions This Supports

• Build vs. buy for internal API tooling. Nimbus replaces most of what a team would otherwise assemble from Postman collections, a Scribe/Scramble install, and ad-hoc seed scripts — for the developer-facing half of that problem. At one composer require and zero licensing cost (MIT), the buy decision is close to free; the real decision is whether to standardize on it versus a hosted API client.
• Developer experience roadmap and iteration-speed investment. The package attacks a measurable toil line: manually authoring and maintaining request collections per endpoint. Auto-discovery from routes plus schema generation from FormRequest, Spatie\LaravelData, and inline validation means the client stays in sync as the API evolves, so the DX win compounds instead of decaying like hand-maintained collections.
• Consolidating the "source of truth" for API shape. Because schemas derive from validation rules rather than from a separate spec, this nudges teams toward treating validation as the contract. That's a useful forcing function for a roadmap goal like "validation coverage on every write endpoint" — gaps become visible as empty request bodies in the client.
• Standardizing API testing practice across squads. Shareable request contexts and persistent, rewindable history let a developer hand a colleague an exact reproduction (headers, body, auth) instead of a screenshot and a paragraph. That's a support-cost reduction and an onboarding accelerator, not just a toy.
• Safer testing of destructive operations. Transaction rollback mode is the standout capability — it makes DELETE/UPDATE endpoints testable locally without seeding a throwaway database per session. This directly affects QA workflow decisions and reduces the "don't touch that endpoint locally" folklore.
• Microservices / multi-surface strategy. Multi-application support (REST, admin, separate services) in one dashboard plus OpenAPI ingestion means the tool can cover a split API estate, not just a single monolith — relevant if the roadmap includes service extraction.
• De-risking auth and session debugging. Auth injection modes (current session, impersonate by user ID, Bearer, Basic) and cookie decryption shorten the loop on permission and session bugs, which are typically the highest-friction class of defect in Laravel apps.
• Where it deliberately does not decide anything: it is explicitly not a documentation generator. If the roadmap item is "publish customer-facing API docs," this is not the tool — pair it with Scribe/Scramble/OpenAPI and let Nimbus stay the playground.

When to Consider This Package

Adopt when most of the following hold:

• The application is Laravel 10–13 on PHP 8.2+ and the API surface is meaningful (roughly: enough endpoints that maintaining a Postman collection is a recurring complaint).
• Endpoints are validated through FormRequest, Spatie\LaravelData, or inline controller validation — that's what the schema generation actually reads. Sparse or inconsistent validation weakens the core value proposition.
• Testing happens locally or in a shared dev environment, and the team accepts a hard rule that the route is dev-only. The impersonation feature alone makes any non-trusted exposure a non-starter.
• You can tolerate alpha software. Current release is 0.x-alpha with breaking changes already shipped (e.g., multi-application config). 346 stars and zero dependents means you are an early adopter, not a follower — budget for reporting bugs and for pinning versions.
• The team's current workflow is "Postman + manual refresh" and the switching cost is low. The payoff is immediate and the rollback is uninstalling a package.
• You want an OpenAPI consumer rather than an OpenAPI producer — Nimbus merges existing specs with route detection, so it complements rather than replaces a documentation pipeline.

Look elsewhere when:

• Public/customer-facing documentation is the requirement. Nimbus says so itself. Use Scribe, Scramble, or a spec-first toolchain.
• CI-level contract or regression testing is the goal. This is an interactive browser client, not a test runner; keep Pest/PHPUnit and schema assertions in the pipeline.
• Non-Laravel services dominate the estate. OpenAPI ingestion helps, but the "Laravel magic" (validation reflection, cookie decryption, dd() capture, transaction rollback) is the actual differentiator and it doesn't apply.
• The team runs php artisan serve or Sail as the primary dev loop and won't adopt the documented workaround — concurrent relay requests can time out on single-threaded servers. Validate this early; it's the most likely source of "it's flaky" feedback.
• Governance is strict about alpha dependencies, unmaintained-by-a-team packages, or anything that can impersonate users. A solo-maintainer alpha with zero dependents is a supply-chain conversation you should have explicitly.
• You need collection-level collaboration (shared workspaces, role-based access, scheduled monitors, environment secrets management). That's Postman/Insomnia territory.

How to Pitch It (Stakeholders)

For executives — one paragraph: Nimbus is a free, MIT-licensed Laravel package that gives engineers a browser-based console for exercising our own API, generated automatically from the code we already write. It removes the ongoing cost of hand-maintaining API test collections and shortens the loop on debugging authenticated and destructive endpoints. Integration is a Composer install and a published config; it is confined to development environments, carries no vendor contract, and can be removed in minutes if it doesn't stick. The main caveat is maturity — it's an alpha with a single maintainer — so we'd pilot it with one squad rather than mandate it.

For engineering — the substance: Install, publish assets and config, hit /nimbus. It statically analyzes our routes and derives request schemas from FormRequest, Spatie\LaravelData, and inline validation, so the client tracks the codebase instead of drifting. Auth is injectable (current session, impersonate by ID, Bearer, Basic), cookies are decrypted for inspection, dd() output is captured in a paginated viewer instead of nuking the response, and destructive calls can run inside a transaction that rolls back. Request history is persistent and rewindable, tabs and UI state persist, and a request context can be shared as a link for exact repro. It ingests existing OpenAPI specs and supports multiple applications from one dashboard. Known constraints: alpha status with breaking changes already in the changelog, php artisan serve/Sail concurrency needs the documented workaround, and the route must never reach production — impersonation by user ID is a live privilege-escalation surface if exposed.

Risk framing and mitigation: Maturity and bus-factor risk → pin the version, pilot on one team, keep Postman collections until the trial proves out. Security → gate the route behind APP_ENV === 'local' (or an explicit allowlist) in the config and verify in the deploy checklist; treat a reachable /nimbus in staging as an incident. Adoption risk → lowest of any tooling proposal, because nothing in the existing pipeline depends on it. Explicit non-goal → this does not replace our API documentation; if we want customer-facing docs, that's a separate decision with a separate tool.