- What does graviton/rql-parser actually do?
- It parses Resource Query Language strings such as ?filter=, ?sort=, ?limit= and ?select= into a structured AST of query objects. The package is framework-agnostic and stops at parsing, so it never executes a query or touches your database. In a Laravel application you get the parsed representation and then hand it to your own Eloquent adapter.
- How do I install graviton/rql-parser in a Laravel project?
- Install it with Composer using composer require graviton/rql-parser. There is no service provider, facade, config file or publishable asset, so nothing is auto-discovered or registered. You typically bind a parser instance as a singleton in your own service provider and inject it into a query-building service.
- Does graviton/rql-parser translate RQL into Eloquent queries?
- No, it only produces an AST and ships no Eloquent support. In its native Graviton ecosystem that AST is translated to Doctrine, so you must write the mapping to where, orderBy, limit and column selection yourself. Budget for that adapter plus a field and operator whitelist as bespoke code you own.
- Is graviton/rql-parser still maintained and does it support PHP 8?
- The repository is archived and the last release was 2019-07-15, so there is no upstream maintenance or CVE response. PHP 8.x compatibility is unverified, and a 2019-era parser may hit deprecations or fatal type errors on PHP 8.1 and newer. Validate it against your target PHP versions before committing, and plan for a vendor fork if you adopt it.
- Is it safe to pass user-supplied query strings to graviton/rql-parser?
- The parser performs no authorization or field-level security, so the RQL string is raw user input as far as the library is concerned. Without a strict whitelist of allowed fields and operators you have an injection and data-exposure vector. You own that policy layer entirely, and it must live outside the parser.
- How does graviton/rql-parser compare to Spatie Query Builder?
- Spatie Query Builder is a maintained Laravel package that maps request parameters directly onto Eloquent queries, including filtering, sorting and includes. graviton/rql-parser gives you only RQL-spec parsing and leaves all query building and validation to you. Choose it only if strict RQL grammar compatibility matters more to you than lifecycle risk.
- Can I use it for sorting, pagination and field selection as well as filtering?
- Yes, the parser handles the standard RQL grammar including filter, sort, limit and select. It returns those as structured AST nodes rather than applying them to a query. You still decide the semantics and defaults, such as maximum page sizes and null ordering, inside your own adapter.
- Is the AST persistence-agnostic or does it depend on Doctrine?
- The output is designed for translation into Doctrine in Graviton's own ecosystem, so treat the AST as Doctrine-flavoured until you inspect it. Check whether nodes carry Doctrine-specific structures you would need to unwrap before mapping them to Eloquent. That inspection is a small but worthwhile part of an initial spike.
- How should I roll out RQL in an existing Laravel API?
- Introduce it behind a versioned endpoint such as /api/v2/{resource} or a feature flag rather than changing existing query-parameter contracts. Run the RQL endpoint and the legacy parameters in parallel during a deprecation window, with per-client usage telemetry to decide cut-over timing. That avoids a flag-day migration and gives you a rollback path.
- Can I fork graviton/rql-parser and maintain it myself?
- The project is archived with no dependents, so a vendor fork is technically straightforward if the license permits it, which you should verify first. Because there is no ecosystem validation, you would be among the first production users and would own every bug fix. Budget maintainer time before adopting rather than after.