Featurit Sdk Symfony Laravel Package

Technical Evaluation

Architecture fit

• The package is still a Symfony bundle, not a Laravel package. Laravel does not use the Symfony bundle/DI/HttpKernel model, so bundle auto-registration, services.yaml wiring, tagged services, and event subscribers will not load.
• Material change in v0.8.0: the bundle now pins PHP SDK 1.0.0 and its headline feature — flexible cache injection — is implemented in the SDK, exposed to Symfony through DI. That confirms the thing the previous assessment gated on: a framework-agnostic core client exists. The bundle is now demonstrably a thin decorator over it.
• That reframes the fit. The bundle is still the wrong artifact for us, but it is no longer a blocker — it is a reference implementation we read and then discard. We integrate the PHP SDK directly.
• Functional intent is unchanged and still sound: FeaturIT is SaaS feature management (kill switches, percentage rollouts, targeting). Opportunity score 7.34 reflects real product value. The 0.02 overall reflects maturity and adoption, and v0.8.0 does not move adoption — still 4 stars, 0 dependents, single maintainer-shaped release history.

Integration feasibility

• Previously: 1–2 days conditional on a core client existing. Now: 1–2 days, unconditional, building against featurit/php-sdk ^1.0 rather than the bundle.
• Work is as before — config/featurit.php, FeaturitServiceProvider, facade, FeatureFlags contract, feature: Blade directive, request-context middleware — plus one new piece: a PSR cache adapter backed by Laravel's cache repository, which the 1.0.0 SDK now accepts via injection.
• Do not take the bundle as a dependency in a Laravel app. Read its services.yaml to learn the intended object graph and cache wiring, then reproduce ~20 lines of it in a service provider.
• Before committing: composer why-not the PHP SDK's PSR/HTTP client constraints against our lockfile, and confirm the PHP version matrix.

Technical risk

• Adoption risk unchanged and still the headline. 0 dependents, no community hardening, no third-party corpus. We will be the ones finding the bugs.
• New risk — fresh major. PHP SDK 1.0.0 is brand new, released the same day as the bundle. The cache injection contract is the newest surface in it and effectively unexercised outside the vendor. Assume the interface is right but the edge cases (TTL semantics, invalidation, serialization) are not.
• New risk — a moving major. The bundle now hard-tracks SDK 1.x. Expect the SDK's 1.x minor cadence to drive bundle minors, and possibly breaking adapter changes on our side if the cache contract firms up. Pin the SDK exactly, not with a caret, for the pilot.
• Runtime risk — partially retired. Custom cache injection was the single largest unknown. It moves from "unknown whether this is usable in a hot path" to "usable if the SDK's cache interface is PSR-compatible and failure behavior is configurable." Both need confirming on the wire, not from release notes.
• Maintenance risk unchanged. Likely vendor-maintained; bus factor and cadence tied to FeaturIT's commercial health.
• Data risk unchanged. Targeting requires sending user attributes to a third party; data residency and PII scope must be reviewed before any customer-facing flag goes live.
• Recommendation: still a spike, not a procurement — but the spike's entry condition is now satisfied. Gate adoption on the SDK's cache failure behavior and a vendor support contract, not on architecture.

Key questions

• Is there a framework-agnostic FeaturIT PHP SDK? Answered by v0.8.0: yes, PHP SDK 1.0.0. Re-evaluate the PHP SDK directly; this bundle becomes documentation.
• Is the 1.0.0 cache interface PSR-16 (SimpleCache), PSR-6, or proprietary? Does it ship a PSR adapter, and can we bind Laravel's CacheRepository in one class?
• What is the failure behavior on vendor timeout — fail-open, fail-closed, last-known-good, coded default — and is it configurable per flag? Does a cache miss block the request?
• Is 1.0.0's cache contract stable, or should we expect a 1.1 to reshape it? What is the SDK's semver discipline and deprecation policy now that it has hit 1.0?
• What is the vendor SLA, uptime history, security disclosure process, and support escalation path?
• Pricing model — MAU, evaluation count, seats? What does flag volume cost at our scale?
• Is self-hosting or an edge/relay deployment available for latency or residency constraints?
• Who maintains the SDK, and how are breaking changes communicated?

Integration Approach

Stack fit

• Target Laravel 11/12 on PHP 8.2+, standard queue workers, optionally Octane. Fit remains adapter-shaped, and the adapter now targets featurit/php-sdk ^1.0 — the Symfony bundle is not a dependency of anything we ship.
• The FeatureFlags interface (isActive(string $flag, ?object $context): bool) with featurit, config, and null drivers is still the single most important decision. It caps lock-in and it is also what insulates us from the SDK's 1.x churn.
• New: a LaravelCacheStore implementing the SDK's cache contract, bound to a dedicated cache store (Redis, separate key prefix) so flag traffic cannot evict or be evicted by application cache.

Migration path

1. Spike (timeboxed, ~1 sprint-week): install the PHP SDK directly — not the bundle — against a throwaway flag in a non-production app. Confirm the cache interface and measure evaluation latency with a cold cache, a warm cache, and a vendor timeout.
2. Adapter: service provider, config, facade, middleware, and the PSR cache bridge as a first-class, tested component rather than an afterthought.
3. Fallback driver: ship the config driver first so every flag has a coded default before any remote dependency exists.
4. Pilot: convert 2–3 low-risk flags in a non-critical service. Instrument defaulted-vs-remote evaluation counts.
5. Broaden: only after a clean pilot and a signed support agreement.

Compatibility

• Pin the PHP SDK exactly for the pilot (1.0.0, no caret) and constrain PSR/HTTP client versions against the host app's lockfile.
• Test explicitly under php artisan config:cache, Octane (client and cache bridge must be stateless or request-scoped), queue workers (long-lived processes holding stale caches), and Dusk/parallel test runs.
• Confirm the SDK does not silently swallow exceptions into a default false — convenient in dev, dangerous in production.
• Note that the bundle's documented cache-injection path is Symfony DI and is not transferable; expect the vendor docs to describe a mechanism we cannot use verbatim.

Sequencing

• Interface and adapter first, cache bridge second, observability third, rollout last. Nothing in a release train should be blocked on the vendor's API availability.
• Because the SDK is at 1.0.0, sequence a re-review of the SDK contract one release later before broadening past the pilot — cheap insurance against a 1.1 that reshapes cache injection.

Operational Impact

Maintenance

• We own the adapter and the cache bridge; FeaturIT owns the SDK. Two artifacts plus upgrade churn on every Laravel major, PHP minor, and SDK minor.
• Budget ~10–15% of one engineer per quarter plus the initial 1–2 day build — unchanged, but front-loaded: the SDK's 1.x settling period likely lands inside our first two quarters.
• Reading the bundle remains a maintenance task in disguise: when the SDK changes shape, the bundle is our fastest signal of intent.

Support

• Anything in a revenue or checkout path requires a commercial support contract. Without one, the 4-star/0-dependent profile means we are the maintainer of last resort.
• Unknown CVE response and disclosure process remains a security-review blocker. A 1.0.0 release does not imply a security process; ask for it explicitly.

Scaling

• Custom cache injection materially improves this: per-evaluation HTTP calls are avoidable, and we control the TTL and refresh policy.
• That control is also a new obligation — the refresh path is ours to build, and bounded memory in Octane workers is ours to verify. Watch both added per-request latency and vendor cost (evaluation count); flag payload growth affects both.

Failure modes

• Vendor outage / timeout / 5xx: must degrade last-known-good cache → coded default. A flag check must never throw into a request path.
• Stale cache — now our problem. With our own cache bound in, the TTL semantics are ours. A bad flag can stay "on" past the incident, and the vendor cannot flush us. We need an app-level kill switch that does not depend on the vendor being reachable. This failure mode is upgraded in severity by v0.8.0.
• Cache misconfiguration: pointing the SDK at the application's default store risks key collisions and eviction under load. Isolate the store and prefix.
• Silent mis-evaluation: wrong user key or missing context yields plausible-but-wrong targeting. Emit metrics per flag (source, value, latency, cache hit) and alert on default-rate spikes.
• Config drift: flags defined in code but not in FeaturIT (or vice versa) fail invisibly; enforce a startup check or a test asserting the flag inventory.

Ramp-up

• The team is Laravel-fluent, not Symfony-bundle-fluent, and this release does not change that — the useful knowledge now sits in the PHP SDK and its cache contract. Expect half a day to a day, plus a short detour to read the bundle's services.yaml for intent.
• Onboard people on the FeatureFlags interface, not the SDK. Keep the wrapper's README short and opinionated; treat the SDK as an implementation detail no one else touches.