Nativephp Fetch Laravel Package

Product Decisions This Supports

• Feature scoping for native/desktop clients. NativePHP Fetch handles HTTP from a NativePHP app; the new macros, base URLs, and response helpers let a small team ship network-dependent features (auth flows, sync, downloads) without building an in-house HTTP abstraction layer.
• Build vs. buy for the HTTP layer. v1.1.0 closes most of the ergonomic gaps that would otherwise justify a custom wrapper: Fetch::baseUrl() with relative URLs (including query strings and downloads) is a config-driven environment switch, and statusIs() plus status helpers (created(), notFound(), unauthorized(), unprocessableEntity(), tooManyRequests()) remove boilerplate error-branching code from every endpoint.
• Standardization / platform-consistency. Fetch Macros are the PM-relevant feature: they let you define one approved request configuration (headers, tokens, timeouts) and reuse it, turning "each dev wires up auth headers themselves" into a reviewable, central convention.
• Observability roadmap. Global FetchRequestStarted / FetchRequestCompleted / FetchRequestFailed Laravel events make network behavior observable through the standard event system — this enables logging, metrics, retry telemetry, and support diagnostics without touching call sites, while #[On] in NativeComponents still works for UI-level handling.
• Risk posture. Explicitly backward compatible: existing request APIs, NativeComponent events, retries, downloads, fakes, and native behavior are unchanged. Adoption can be incremental with no migration budget.

When to Consider This Package

Adopt when:

• You are building a NativePHP desktop/mobile app and need HTTP from the native runtime rather than a browser context.
• You want one place to govern request configuration (tokens, timeouts, headers) across a codebase — macros plus base URLs cover this.
• You need cross-cutting visibility into request success/failure for logging or support tooling — the global events are the deciding factor.
• You value the testing story: fakes and retries remain intact and unchanged.

Look elsewhere when:

• The product is a conventional web app — Laravel's Http client already covers this; Fetch adds a native-runtime dependency without benefit.
• You need advanced HTTP semantics not evidenced here (streaming, complex multipart, granular connection pooling, custom transport/interceptors beyond macros).
• You require a stable, long-supported API surface with vendor SLAs — this is a young, fast-moving package; pin versions and keep the abstraction thin.
• Your observability stack is external (APM-only) and you'd rather not route through Laravel events.

How to Pitch It (Stakeholders)

To executives: This release makes network code in our native app cheaper to build and easier to govern. Reusable request configurations mean auth headers and timeouts are defined once instead of scattered across features, which reduces both defect surface and review time. Standard response helpers cut repetitive error-handling code, and built-in global request events give us visibility into failures for support and reliability work — capability we would otherwise build ourselves. It is backward compatible, so there is no rework cost to adopt.

To engineering: v1.1.0 is a DX release. Use Fetch::baseUrl() for environment-driven relative URLs, define macros for shared headers/tokens/timeouts, and prefer statusIs() / status helpers over manual code comparisons. Listen to FetchRequestStarted/Completed/Failed globally for logging and metrics — #[On] still works in NativeComponents. Everything existing continues to work; adopt incrementally and pin the version, since the API is still evolving.