- What is Requent and what does it do in Laravel?
- Requent is a Laravel package that provides a GraphQL-like interface for mapping an incoming request to an Eloquent query. It supports client-selected fields, relations, filters, and data transformations, replacing hand-written controller and query code with a declarative schema. It sits at the HTTP-to-Eloquent boundary and is intended for read endpoints where clients want field selection without adopting full GraphQL.
- Is Requent still maintained or abandoned?
- Requent is effectively abandoned: its last release was on 2017-06-26, roughly eight years ago, with a single maintainer and no visible release cadence. It has about 78 GitHub stars and zero dependents, so there is little community usage to surface bugs or security reports. Any vulnerability in its request-parsing or query-building path would be yours to fix.
- Which Laravel and PHP versions does Requent support?
- The package targets PHP 7.0 and 7.1 and predates Laravel 5.6. Its native fit is Laravel 5.4 through 5.5, where no engineering work is required. Laravel 5.6 through 6.x may work only after loosening Composer constraints and running a regression suite, and it does not fit Laravel 8+ or PHP 8.x without a fork.
- Can I install Requent on Laravel 10 or Laravel 11?
- No, Requent will not install cleanly on Laravel 10 or 11. Its illuminate/* constraints predate Laravel 5.6 and will not resolve against Laravel 8, 9, 10, or 11, which require PHP 8.1+ and Symfony 6. You would need a maintained fork with dependency modernization and test coverage, which is a small internal project rather than a Composer require.
- How does Requent handle authorization for fields and relations?
- Requent does not remove the need for authorization; because clients can request fields and relations, you must enforce field- and relation-level authorization per model. The package concentrates risk at the request-mapping layer, so allowlists and policy checks must be explicit. Verify in the source how filters are bound and how errors are handled before trusting it with sensitive data.
- Is Requent safe to use in production?
- Adopting Requent in production is high risk without a legacy constraint. It runs on an unsupported PHP runtime, has no security patching, and has almost no downstream usage to validate edge cases. If you must use it, isolate it behind an adapter, enforce depth and page-size limits, and own the fork.
- What are the alternatives to Requent for query building in Laravel?
- The closest maintained alternative for declarative queries is spatie/laravel-query-builder, which supports filters, sorts, and includes with explicit allowlists. If clients genuinely need a graph-style contract, Lighthouse provides GraphQL on Laravel with schema and resolver ownership. For field selection only, Laravel API Resources with sparse fieldset handling has the lowest dependency risk.
- How do I install Requent with Composer?
- Composer installation is trivial in principle: require sheikhheera/requent in a compatible Laravel 5.4 or 5.5 project on PHP 7.0 or 7.1. On current stacks it is near-certain to fail dependency resolution because of its old illuminate/* constraints. Confirm the exact version constraints in composer.json and expect to fork for anything newer.
- Does Requent protect against SQL injection and denial-of-service queries?
- SQL injection risk depends on how Requent binds filters, which must be verified in the source rather than assumed. A request-driven query mapper also concentrates denial-of-service risk: unbounded depth, relation traversal, or page size turns a read endpoint into an attack vector. Enforce allowlists, cost limits, and maximum page sizes before exposing it.
- Should I use Requent for a new Laravel project or only for legacy apps?
- Use Requent only for a legacy Laravel 5.x application with sunk client investment and a large surface of read endpoints, and only if a maintained fork is costed and owned. For greenfield or modern stacks, choose a maintained package such as spatie/laravel-query-builder, Lighthouse, or API Resources. The requirement is usually fewer endpoints or field selection, and those have safer answers.