Getting Started

Install: composer require sheikhheera/requent. The package was last tagged in June 2017, so before committing, check that your composer.json Laravel/PHP constraints haven't moved past what it supports (it was built for the Laravel 5.x era). Run composer why-not sheikhheera/requent if resolution fails.
Register the service provider. On Laravel ≤5.4 manually add Heera\Requent\RequentServiceProvider to config/app.php; on 5.5+ it should be auto-discovered. If it isn't, that's your first sign the package is unmaintained for your version.
Publish/read the config: php artisan vendor:publish --tag=requent (check vendor/sheikhheera/requent/config for the exact tag). This is where the query parsing and field-selection defaults live.
Read the README and any tests/ or examples/ directory in vendor/ first — for a package this old, the tests are the most reliable documentation of the expected query-string syntax.
First use case: pick a single read-only endpoint (e.g. GET /api/posts) and confirm you can pass a Requent-style query string, get back only the fields and relations you asked for, and see the underlying query logged via DB::listen or Laravel Telescope. If that round-trip works, the package is worth building on.

Implementation Patterns

Route-plus-resolver, not magic. Add an explicit route per model and a small resolver that maps the incoming string to a base Eloquent builder. Keep the model class in your code, never let the request select the model.
Whitelist fields and relations in a schema map. Define per-resource arrays (or a config block) of allowed columns and relations, resolve those to select() and with() on the builder. This is where you get the "GraphQL-ish" benefit without the "arbitrary query execution" risk.
Transform after query. Use Eloquent filter()/collection transforms or Laravel API Resources on the result set — Requent shapes the query, so keep response shaping in a presenter layer that you control.
Middleware for parsing/caching. Parse once in a middleware, attach the parsed request to the container ($request->attributes or app()->instance()), and let controllers consume it. Add a cache key derived from the normalized query string if the endpoint is hot.
Compose with existing scopes. Apply authorization scopes (->where('user_id', auth()->id())) before handing the builder to Requent so user-supplied filters can't widen results.
Version the contract. Because the query string is now an API surface, document the syntax and add one or two integration tests per resource in CI.

2017 dependency graph. PHP 7.x and Laravel 5.x era. Check composer.lock conflicts before adding; you may need --ignore-platform-reqs in a sandbox, which is a red flag for production. Fork-and-patch is the realistic path if you depend on it.
No built-in authorization or pagination guarantees. Always apply auth scopes and a hard limit()/paginate() cap; otherwise a crafted query string can request unbounded relations (N+1 and memory blow-ups).
Field selection is not validation. Reject unknown field/relation names with a 422 rather than silently dropping them — silent drops make client bugs invisible.
Debugging: wrap the resolution step in a try/catch that logs the raw query string plus the SQL (DB::enableQueryLog()), and log when a field is filtered by the whitelist. The package's own exceptions are unlikely to be descriptive.
Extension points: the cleanest long-term move is to wrap Requent in your own QueryBuilder/Schema classes so you can swap it out (for Lighthouse, laravel-query-builder, or a hand-rolled parser) when its compatibility finally breaks — the rest of your app shouldn't import the vendor namespace directly.
Testing: assert on SQL and JSON shape, not on vendor internals — you'll want those tests to outlive the package.