Laravel Abtest Laravel Package

Technical Evaluation

Architecture fit

abrouter/laravel-abtest is a thin Laravel client for ABRouter, a hosted (or self-hostable) A/B testing and feature-flag control plane. Architecturally it is a control-plane/data-plane split: experiment configuration and statistical analysis live in ABRouter, while bucketing decisions are consumed inside the Laravel app at request time. That model fits Laravel well — server-rendered Blade views, middleware, jobs, and API responses can all branch on either a flag state or an experiment variant.

For a TPM the real architectural question is not "does it integrate" (it will — it's a Composer package with a service provider and facade) but "where do we draw the boundary." The package is designed to be called from controllers, Blade, and services directly via facades and directives. That is convenient but couples business logic to a third-party SDK. The sound pattern is to wrap ABRouter behind an internal FeatureFlags / ExperimentService interface so the rest of the codebase never imports the vendor namespace. Treat ABRouter as one provider behind that interface, not as the interface itself.

Integration feasibility

Low-to-moderate. Typical integration is:

1. composer require abrouter/laravel-abtest
2. Auto-discovered service provider registers the facade
3. Publish config, supply an API token and host via environment variables
4. Resolve the current user identifier (usually Auth::id(), but must be stable and consistent across web, queue, and API contexts)
5. Call the flag/branch API in a controller or Blade directive

That is realistically a day of work for a competent Laravel developer for a single experiment, not the "10 minutes" the README markets (which excludes account provisioning, user-ID strategy, and analytics wiring).

Technical risk

• License — the dominant risk. GPL-3.0 on a PHP client library consumed by a proprietary application is legally uncomfortable. PHP has no clean "linking" boundary, and many legal teams treat GPL composer dependencies in a closed-source product as requiring review or avoidance. This should gate adoption until counsel signs off. Most competitor SDKs (LaunchDarkly, Unleash, Flagsmith, GrowthBook, Laravel Pennant) are MIT/Apache — the asymmetry is real.
• Bus factor / community. 109 GitHub stars and a single-vendor ecosystem means limited third-party hardening, sparse Stack Overflow coverage, and a higher chance of undetected edge cases. A 2025-05 release is a good maintenance signal but not a guarantee of long-term velocity.
• Availability coupling. Every flag evaluation is a potential network call. If ABRouter cloud is unreachable and there is no local cache/fallback, the failure surfaces directly in user requests — unless a fail-open/fail-closed policy is defined per flag.
• Data egress / privacy. User identifiers and possibly traits are sent to a third party (or your self-hosted instance). GDPR/DPA review is required, especially for consumer products.
• Hidden coupling to user identity. Bucketing is only stable if the same identifier is used on web, mobile API, and background jobs. Getting this wrong produces inconsistent variants and invalid experiment results — a common and expensive mistake.

Key questions to resolve before committing

1. Is GPL-3.0 acceptable to legal for a distributed or SaaS product, or does it force a fork/self-host under different terms?
2. Do we need self-hosting for data residency, and if so, what is the operational cost of running the ABRouter core service?
3. What is the evaluation latency budget, and does the package cache locally or hit the API per call?
4. What is the documented behavior when ABRouter is unavailable — default variant, exception, or null?
5. Does ABRouter provide the statistical rigor we need (sample-size guidance, sequential testing corrections, guardrail metrics), or only bucketing plus a basic dashboard?
6. What is the exit cost — can we export experiment definitions and historical exposure data?
7. Is the free cloud tier rate-limited or SLA-backed, and what does paid support look like?

Integration Approach

Stack fit

Strong for a conventional Laravel monolith (Laravel 8–12, PHP 8.1+ — verify the exact composer.json constraints against our pinned version). Fits less naturally for a service-oriented architecture where flags are also needed by non-PHP services (Node workers, Go microservices); those would each need their own ABRouter SDK, multiplying the identity and consistency problem. If the platform is Laravel-heavy, the fit is good; if polyglot, ABRouter becomes one more vendor surface to standardize.

Migration path

• Phase 0 — Legal and data review on GPL-3.0 and the DPA. Non-negotiable gate.
• Phase 1 — Abstract first. Define an internal ExperimentGate interface with two implementations: a NullGate (always control/off) and an ABRouterGate. Ship with NullGate in production so nothing depends on the vendor until explicitly enabled.
• Phase 2 — Pilot. One low-risk, non-revenue flag (e.g., a UI copy variant) behind ABRouterGate, enabled via config. Measure evaluation latency and failure rate.
• Phase 3 — Promote. Move to one real experiment with a defined metric and guardrail. Only then expand to a second use case.

Compatibility

Coexists cleanly with Laravel Pennant if the teams are disciplined: Pennant for static, deploy-time, developer-owned flags; ABRouter for product-manager-owned, dynamically targeted flags and experiments. Running both for the same flag is a guaranteed source of confusion and should be banned by convention.

Sequencing

The critical path runs through legal, not engineering. Start GPL review in week 1 in parallel with a two-day technical spike. Do not let the spike's success create organizational momentum that overrides the license decision — a common failure mode with convenient developer tools.

Operational Impact

Maintenance

Package maintenance is light (Composer update + occasional config changes). The heavier maintenance is experiment hygiene: stale flags accumulating, experiments left running past significance, and targeting rules that no one remembers authoring. Budget for a flag lifecycle policy (owner, expiry date, cleanup on rollout) from day one, or the flag inventory becomes technical debt within two quarters. If self-hosting ABRouter, add infrastructure maintenance for the core service, its database, and backups.

Support

The free cloud tier effectively means community/GitHub support with no SLA. For a revenue-affecting experiment platform, decide in advance whether a paid tier is budgeted; if not, accept that an outage is a "we wait" scenario rather than a "we escalate" one.

Scaling

Evaluation throughput scales well because bucketing is deterministic and cacheable; the API call is the bottleneck, not the compute. Ensure the package's cache is enabled and sized appropriately and that cache invalidation on flag changes is acceptable (some staleness is normally fine; for kill-switch flags it is not). Exposure event logging is the second scaling concern — high-traffic endpoints generating exposure events per request can produce significant write volume and should be sampled or batched.

Failure modes to design for explicitly

• ABRouter API unreachable → per-flag fail_open / fail_closed policy, defaulting to the safe variant (typically control).
• Token rotation or misconfiguration → health check on startup, alert on flag-evaluation error rate.
• Inconsistent user identifiers across web/queue/API → variant assignment drift, corrupted experiment results.
• Silent flag deletion or rename in the dashboard → runtime default; add a startup validation of referenced flag keys.
• Cache poisoning or stale kill-switch → short TTL for operational flags, longer for experiments.

Ramp-up

Developer ramp-up is genuinely short — a few hours to first flag, a day to production quality. Product-manager ramp-up on the ABRouter dashboard and experiment design (metric definition, sample size, guardrail selection) is the longer curve and is not solved by the package. If the team lacks experimentation discipline, the tool will produce confidently wrong conclusions. Pair adoption with a short internal playbook on experiment design and a review step before any experiment is launched.