Sdk Laravel Laravel Package

Product Decisions This Supports

• Analytics instrumentation strategy. The package is a thin, opinionated wiring layer over mirafive/sdk-php: buffer events in the request, flush on terminate / Octane request end / task / tick / queued job. That's the decision point for "how do we collect product events without paying latency on every request" — it answers it with a queue-backed hand-off (MIRAFIVE_QUEUE, SendBatch) and a synchronous escape hatch (send()).
• Build vs. buy for the event pipeline. If the alternative is a homegrown Event::listen + HTTP client + retry logic, this is a cheap buy: composer require, auto-discovered provider, publishable config. If the alternative is a full CDP (Segment, PostHog, RudderStack), this is a narrower commitment and should be scoped as such.
• Feature flag rollout and progressive delivery. MiraFlags + cache-shared flag document + @mirafiveFlags($unit) bootstrap block supports gating features per unit/tenant without a second vendor. This is what lets a PM ship behind flags rather than behind a release train.
• Consent and privacy posture. Disabled mode (enabled false or no secret key) means nothing leaves the process and no key is required — useful for local, CI, and self-hosted deployments. Separate mode (server events) and script_mode (tracker tag, default consentless) is a genuine product lever: you can run server-side collection while holding back the client tag, or vice versa.
• Identity and opt-out semantics as first-class features. Mira::forUser($user) and Mira::optedOut($request) mean the "who is this event about" and "did they say no" decisions are encoded in one place rather than sprinkled across controllers. That directly affects data-quality and compliance reporting.
• Roadmap sequencing for flags vs. analytics. Because flags share a cache store and arrive through a Blade bootstrap block with Cache-Control: private, no-store, flag work and event work can be sequenced independently — pick one, prove it, then turn on the other.
• Release gate / launch readiness. php artisan mirafive:check sending $install_check and printing a receipt is a shippable verification step for a go-live checklist. Combined with Mira::fake() and its assertions (assertTracked, assertNotTracked, assertIdentified, assertNothingTracked), event instrumentation becomes testable in CI rather than trusted by eyeball.
• Infrastructure decisions that touch product. Octane-safe flushing and the requirement for a Laravel cache store are deployment decisions, but they gate whether flags are consistent at all — worth a PM seat at that table.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP — this is the whole premise. Non-Laravel or polyglot services should go straight to mirafive/sdk-php or elsewhere.
• You want server-side product events plus feature flags from a single dependency, and you're comfortable with MiraFive as the vendor/backend.
• You run Octane, queue workers, or scheduled tasks. Flush-on-terminate semantics are the part most in-house implementations get wrong; this release handles it explicitly.
• Consent is a real constraint (EU users, regulated data). Disabled mode with input still validated, plus optedOut(), gives you a defensible default without building a consent layer.
• Testing matters. The fake + assertion surface is unusually complete for a v1 SDK; teams that can't assert on emitted events tend to stop maintaining them.
• You need graceful degradation: no secret key should not mean broken pages.

Look elsewhere or defer when:

• This is v1.0.0 and the first Laravel wrapper — budget for interface churn. Config keys (mode, script_mode, MIRAFIVE_QUEUE) are the most likely places for breaking changes.
• You need experimentation statistics (significance, sequential testing, sample-ratio checks). Flags alone are not an experimentation platform; pair with something or accept manual analysis.
• You need a multi-destination CDP (warehouse + ad platforms + CRM). Single-vendor SDK, single destination.
• You need warehouse-native or self-hosted analytics with SQL access to raw events.
• Your cache store is unreliable or per-node without sharing. The shared flag document depends on it; with the array driver or per-pod local caching, flags will diverge across requests.
• script_mode: consentless by default is a red flag until reviewed. Ship the default only after legal/privacy sign-off; plan to switch to a consent-gated mode for regulated traffic.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add product analytics and feature flags to the Laravel application with one dependency and a single config file. It is off by default and safe by default: with no key configured it sends nothing and breaks nothing, and it has an explicit opt-out path per user, which is the part auditors ask about. It runs collection off the request path via the queue, so page performance does not regress, and it ships with a self-test command plus a testing harness so we can verify instrumentation in CI rather than discovering gaps post-launch. Cost is a vendor commitment to MiraFive and acceptance of v1.0.0 maturity risk.

For engineering (the practical summary): composer require mirafive/sdk-laravel, provider and Mira facade auto-discovered, php artisan vendor:publish --tag=mirafive-config to get config/mirafive.php. Buffers flush on terminate, after each Octane request, task, tick, and queued job; flags are warmed under Octane and shared via a cache store — so pick a real shared cache backend. Set MIRAFIVE_QUEUE to hand off encoded batches to SendBatch for byte-for-byte worker delivery with its own key; send() stays synchronous for cases where you need it. Views get @mirafiveScript (hosted tracker with website key and Vite CSP nonce) and @mirafiveFlags($unit) (bootstrap block, served private, no-store — expect it to bypass CDN caching). Use Mira::fake() and the assert helpers in tests, and php artisan mirafive:check in the deploy checklist.

The trade-off to state plainly: this is a first release of a wrapper around a first major of the underlying SDK. Expect config and API churn, and treat the consentless default tracker mode as something to consciously approve rather than inherit.