Rulerz Bridge Laravel Package

Technical Evaluation

What we are actually evaluating. The package is frontastic/rulerz-bridge — a Symfony bundle that wires the RulerZ rule engine into a Symfony DI container: it registers rule compilers, operators, and an executor service so application code can resolve and apply a rule DSL. The asset underneath it is RulerZ core (the parser/compiler), which is framework-agnostic. The bridge is a thin, vendor-specific adapter. This distinction drives the entire assessment.

Framework mismatch is the headline. Our runtime is Laravel/PHP, not Symfony. The bridge depends on Symfony Bundle, DependencyInjection, tagged service collections, and compiler passes — none of which Laravel consumes. In practice this package is not a drop-in dependency for us; it would pull Symfony components into a Laravel app for no functional gain. The capability we might want (declarative, storable business rules compiled to query constraints) lives in RulerZ core and is installable via Composer independently. A TPM should treat this repository as a reference implementation of the wiring pattern, not as a candidate composer require.

Architecture fit.

• Good fit for the capability: eligibility checks (promotions, coupons, tiered pricing, free-shipping thresholds), customer segmentation, merchandising/pin-boost rules in listings, content targeting, feature gating. The value is one rule syntax evaluated consistently across heterogeneous targets — Eloquent/query-builder pushdown for production, in-memory arrays for preview/dry-run.
• Poor fit for the package: a Laravel shop gains nothing from Symfony service tags. Reimplementing the equivalent as a Laravel service provider is on the order of a small, well-understood file — the "glue" is not the hard part.
• Poor fit for the problem in general if rules are static and engineer-owned: symfony/expression-language-equivalent (or plain config flags and policies) is cheaper to own and easier to reason about than introducing a DSL, parser, and compilation layer.

Integration feasibility. Mechanically low-effort, but not free. The real work is (a) confirming PHP version constraints against our runtime, (b) deciding whether to bind our domain code to RulerZ's API surface, and (c) designing the authoring/validation story that neither RulerZ nor this bridge provides. Composer install of the bridge itself is likely to drag in Symfony packages we do not otherwise want — a direct cost (dependency surface, advisory noise, upgrade friction) with no offsetting benefit on Laravel.

Technical risk.

• Adoption signal: effectively zero. 0 stars, 0 dependents, score 0.03. No external validation, no user base to surface regressions, no issue-tracker history to lean on. We would be first movers on an artifact published primarily for Frontastic's own application.
• Bus factor. Single-vendor, and the vendor (Frontastic/commercetools) has no stated support relationship with this repo. Archival or privatization transfers maintenance to us wholesale.
• Version drift. Bridges of this vintage typically pin older Symfony/PHP constraints. On Laravel, the concern inverts: the bridge is irrelevant, but we still must verify RulerZ core's PHP support against our target version.
• Security surface. RulerZ compiles DSL into query builders. If rules ever originate from non-developers, persisted config, or an admin UI, we own operator allow-listing, input validation, and resource-exhaustion limits. The bridge does not solve this, and it is the single largest design obligation in the whole capability.
• Abandonment cost is capped — the code is thin, MIT, and forkable. But that same fact is the argument for not taking the dependency at all.

Key questions for the spike.

1. Is this a fork/re-publication of kp-rulerz-bundle, and which upstream commit does it track?
2. What Symfony/PHP matrix is it actually tested against, versus aspirational constraints in composer.json?
3. Which compilers ship and are supported (array, Doctrine ORM, Elasticsearch, custom)? Is there anything Laravel/Eloquent-adjacent, or would we write that adapter ourselves?
4. Is RulerZ core actively maintained, and what is its release cadence?
5. Does the bridge add anything beyond container registration that we could not reproduce in a Laravel service provider in a day?
6. Any guidance on caching compiled rules and sanitizing author-supplied rules?

Integration Approach

Stack fit and the correct target. Do not integrate the bridge. Adopt RulerZ core (if at all) behind a Laravel service provider that binds an executor, an operator allow-list, and compiler configuration from config/rules.php. The bridge's contribution is a working example of which operators and compilers to register and how to expose the executor — read it, do not depend on it.

Build vs. adopt, framed as a cost decision. "Buy" here means MIT-licensed OSS at zero license cost but nonzero lifecycle cost. The genuine comparison is three-way:

• Managed rules/flagging platform — pays for authoring UI, audit, SLAs; right answer if business users must author rules.
• Glue RulerZ core into Laravel — right answer if engineers/technical ops author rules in config and we need multi-target evaluation.
• Hand-write conditions (Laravel policies, config flags, a small expression evaluator) — right answer if rules are few and stable.

This package sits inside option two but contributes nothing that option two needs on Laravel. Score it on total cost of ownership, not on license price.

Migration path / sequencing.

1. Timeboxed spike (1–2 days, one engineer). Install RulerZ core directly in a branch, hand-wire a service provider, define two representative rules, execute one against an in-memory collection and one against an Eloquent/query-builder target. Measure compile cost and evaluation cost. Explicit success criterion: if hand-wiring is under a day — and it should be — the bridge is definitively out.
2. Isolate behind our own interface. RuleEngine contract plus a Rule value object; no domain or controller code imports RulerZ types. This makes a later swap to a hosted decision service or to a fork a contained change rather than a refactor.
3. Pilot one bounded use case with developer-authored rules only — never user-authored — behind a feature flag.
4. Expand only after compiled-rule caching, rule versioning, and dry-run/preview against a sample set exist.

Compatibility and sequencing controls.

• Pin exact versions; commit the lockfile; record the PHP constraint check as a gate before the pilot, not during it.
• Explicitly reject the bridge's transitive Symfony dependency footprint in code review; document why in the ADR so it is not re-litigated.
• Land the abstraction and the flag before any business rule moves into the DSL, so rollout and rollback are configuration changes, not deploys.
• If the core fails the PHP constraint check, decide immediately between a vendored patched fork and abandoning the capability — do not defer into the pilot.

Migration if a bridge-like dependency is ever forced on us (e.g., we acquire a Symfony service): wrap it behind the same RuleEngine interface. The interface is the portability insurance; the concrete engine is replaceable.

Operational Impact

Maintenance. We own the capability regardless of package choice. The bridge adds nothing to own and something to patch, so drop it. Ongoing obligations are: tracking RulerZ core releases (or vendoring it), maintaining our adapter and operator allow-list, and periodically re-asking whether the DSL still earns its keep versus plain code. Vendor or fork the core so an upstream archive is a non-event rather than an incident.

Support. No SLA, no vendor relationship, no responsiveness to depend on. Escalation terminates at our own engineers. State this in the ADR and in on-call documentation rather than letting it be discovered mid-incident. If a managed rules platform is on the roadmap, name the trigger conditions now (business-user authoring, audit requirement, cross-service rule sharing) so the migration is a planned decision.

Scaling — two dimensions.

• Rule volume and authoring rate: parse/compile cost grows with rule count and complexity. Cache compiled rules keyed by rule version; never compile on a per-request or per-item path.
• Evaluation surface: prefer compiler pushdown into the database query; filtering large collections in PHP will dominate latency and memory. For Laravel specifically, the Eloquent/query-builder adapter is ours to write and benchmark — that adapter, not the DSL, is where performance risk concentrates. Establish benchmarks during the pilot.

Failure modes and their blast radius.

• Rule compilation error at runtime → request failure. Mitigate by validating at save/authoring time, not evaluation time.
• Unknown operator / unsupported compiler → silent fallback or hard exception depending on config; assert the intended behavior in tests.
• Silent misclassification after a rule edit → highest severity, because it looks like normal operation and surfaces as revenue or eligibility errors weeks later. Requires rule versioning, change audit, and dry-run against a sample set before activation.
• Dependency breakage on a PHP/framework upgrade → blocks platform upgrades. The interface wrapper bounds this; the bridge would widen it.
• Injection / resource exhaustion via author-supplied rules → allow-list operators, cap rule complexity, and never evaluate unreviewed rules in production.

Ramp-up. The DSL is small and approachable; debugging a failed compile is a specialist skill. Designate one or two owners, write an internal guide covering the supported operator set and authoring conventions, and constrain early rules to patterns already validated. Do not open authoring to non-engineers until validation, preview, and audit exist — that is a product build, not a library configuration.

TPM recommendation. Frame this to stakeholders as a capability decision, not a package decision. The package is a low-signal, framework-mismatched artifact whose only durable value is as a design reference; the underlying engine is the asset. Fund a short spike to confirm RulerZ core's compatibility and measure the build-vs-glue delta against Laravel's service container, defaulting to hand-wiring core behind our own interface unless the spike shows otherwise. Scorecard outcome: do not adopt frontastic/rulerz-bridge; evaluate RulerZ core for one bounded use case this quarter.