Requent Laravel Package

Technical Evaluation

Architecture fit. Requent sits at the HTTP-to-Eloquent boundary and replaces hand-written controller/query code with a declarative, client-supplied request schema (field selection, relations, filters, transformations). That is a deliberate architectural bet on client-driven querying. It fits a narrow case: a legacy Laravel 5.x application with a large, growing surface of read endpoints, where clients want field selection but a full GraphQL adoption is too heavy. For a greenfield or modern stack, it is a layer you would rather not own — the same capability is available from maintained packages with an active security posture.

Integration feasibility. Composer installation is trivial in principle and near-certain to fail in practice on current stacks. The last release (2017-06-26) predates Laravel 5.6, so its illuminate/* constraints will not resolve against Laravel 8/9/10/11 (PHP 8.1+, Symfony 6). Feasibility without a fork: low. With a maintained fork and a compatibility pass: moderate, but you are now the maintainer of a query engine.

Technical risk: high.

• Abandonment. Roughly eight years without a release, no security patching, single maintainer, no visible release cadence. Any CVE in the request-parsing or query-building path is yours to fix.
• Runtime exposure. It targets PHP 7.0–7.1; PHP 7.4 reached end of life in November 2022. Adopting it implies running an unsupported runtime or porting it forward.
• Attack surface. A request-driven query mapper concentrates risk: field- and relation-level authorization must be enforced per model, and unbounded depth, relation traversal, or page size turns a read endpoint into a denial-of-service vector. SQL injection risk depends on how filters are bound — this must be verified in source, not assumed.
• No ecosystem validation. 78 stars and 0 dependents means almost no downstream usage to surface bugs, edge cases, or security reports. There is no community forcing function keeping it correct.
• Behavioral coupling. Client contracts become coupled to model/schema internals; a rename or relation change silently breaks consumers.

Key questions.

1. Is there a hard constraint (existing Laravel ≤5.5 app, sunk client investment) that makes this the cheapest path, or is this a greenfield choice?
2. What is the actual requirement — client-selected fields and relations, or simply fewer endpoints? The latter has safer answers.
3. Who owns the fork, and is that costed? If nobody will own it, the answer is no.
4. Has the request-mapping surface been threat-modelled: per-field authorization, depth/cost limits, filter binding, error handling?
5. Is GraphQL (e.g., Lighthouse), spatie/laravel-query-builder, or plain API Resources with sparse fieldsets an acceptable substitute? In most cases it is, and it is maintained.
6. What data sensitivity and blast radius sit behind the endpoints in scope?

Assessment: conditional no-go absent a legacy constraint. The 0.57 score is consistent with the evidence — usable idea, unmaintained artifact.

Integration Approach

Stack fit.

• Native fit: Laravel 5.4–5.5 on PHP 7.0–7.1. This is the only combination that requires no engineering work.
• Likely fit with verification: Laravel 5.6–6.x, after loosening constraints and running a regression suite. Treat as unproven until tested.
• Does not fit: Laravel 8+ / PHP 8.x. Requires a fork, dependency modernization, and test coverage — a small internal project, not a composer require.

Migration path and alternatives. Run a short bake-off before committing:

• spatie/laravel-query-builder — filters, sorts, includes, maintained, explicit allowlists; closest drop-in for the "declarative query" need with a safer default posture.
• Lighthouse (GraphQL on Laravel) — if clients genuinely want a graph-style contract and the team can absorb schema and resolver ownership.
• Laravel API Resources plus sparse fieldset handling — lowest dependency risk where the requirement is field selection only.

If Requent is chosen, isolate it behind an adapter/facade (a single "query gateway" interface) so the engine can be replaced without touching controllers or clients. That inversion is the main thing that makes the decision reversible.

Compatibility work. Pin an exact version and commit the lockfile. Audit composer.json constraints against the target Laravel version. Stand up the app on a pinned PHP 7.4 container image with a documented end-of-life exception. Because upstream ships no releases, dependency scanners will not surface fixes — add it to the manual patch register.

Sequencing.

1. Spike (≈1 week). Install in a sandbox, exercise the request schema, read the source for filter binding and authorization hooks, and write down what is actually enforced.
2. Threat model and security review. Field/relation authorization, depth and cost caps, input validation, error semantics. Gate: no pilot without sign-off.
3. Adapter and contract tests. Wrap behind the gateway interface; capture request/response fixtures so a later replacement can be verified.
4. Pilot. One read-only, low-sensitivity endpoint with a bounded schema. Instrument query count, latency, and error rate.
5. Decide. Expand only if the pilot shows acceptable query cost and no authorization gaps; otherwise exit via the adapter with minimal sunk cost.

Operational Impact

Maintenance. Ownership transfers to your team the day it is merged. Expect to maintain a fork, carry PHP and Laravel upgrade work, and patch security issues without upstream. Budget this as an ongoing line item, not a one-time integration cost.

Support. No vendor, no maintained documentation, no release notes, and a community too small (0 dependents) for reliable answers. Troubleshooting means reading the package source. This is acceptable for a small, stable, well-understood codebase and unacceptable for a business-critical path without a named owner.

Scaling. The package generates queries dynamically, so cost is a function of client input, not code review. Expect N+1 patterns, missing-index scans, and expensive relation joins under real traffic. Mitigations are mandatory, not optional: allowlisted fields and relations, maximum depth and relation count, hard page-size caps, per-request query budgets, and APM instrumentation on generated SQL. Scaling the PHP tier does not fix a database being hammered by unbounded queries.

Failure modes.

• Authorization bypass — clients requesting relations or fields not covered by policy; the highest-severity mode.
• Resource exhaustion — deep or wide relation graphs causing memory or database pressure; surfaces as latency spikes and 5xx under load.
• Silent schema drift — model renames or relation changes break client contracts with no compile-time signal.
• Error-handling degradation — malformed requests returning 500s instead of 422s, complicating client retries and on-call triage.
• Upgrade dead-ends — being unable to move to a supported Laravel or PHP version without a port project.
• Bus factor — one engineer understands the mapping semantics; departure becomes an incident.

Ramp-up. The codebase is small; a mid-level Laravel engineer can become productive in a few days and fluent in one to two weeks. The real cost is the missing specification: behavior must be reverse-engineered from source and encoded in adapter contract tests and an onboarding note. Plan for that documentation effort explicitly, and keep at least two engineers familiar with the query gateway so the knowledge does not concentrate in one person.