- What does Eloquentify do and when should I use it?
- Eloquentify is a Laravel package that takes the result of a single custom SQL query and hydrates it into fully nested Eloquent models. You write one query that aggregates each relation into a JSON column named after the relation method, then call User::eloquentify($result)->first() to get real models back. It is aimed at read-heavy, latency-sensitive endpoints where N+1 lazy loading or R+1 eager loading round trips are too expensive. Because it requires hand-written SQL, it fits teams with SQL fluency better than teams that have standardized on never writing raw SQL.
- How do I install and configure Eloquentify in a Laravel app?
- Install it with composer require kobykorman/eloquentify. Add the EloquentifiesQueries trait to your base model or to individual models, and that is the entire configuration. There is no service provider, facade, or config file to publish, and no schema changes are required. The real setup work is authoring the per-relation JSON aggregation SQL for each endpoint.
- Which Laravel and PHP versions does Eloquentify support?
- The README does not publish an explicit Laravel or PHP version matrix, so treat support as unconfirmed until you check composer.json and the CI configuration in the repository. The package is a single trait with no framework-level hooks, which suggests it works across recent Laravel releases, but that is an inference rather than a documented guarantee. Verify the version constraints and tag state directly before committing to it in a production application.
- Which databases work with Eloquentify: PostgreSQL, MySQL, or SQLite?
- The examples in the README use PostgreSQL's json_build_object and json_agg, which is clearly the primary target. MySQL 8+ equivalents such as JSON_OBJECT and JSON_ARRAYAGG, and SQLite's json_group_array, should also work, but the aggregation SQL is driver-specific and must be rewritten per database. The project does not document a formal driver test matrix, so validate your exact queries against every environment including CI.
- Do Eloquent casts, accessors, $appends, and timestamps still work on hydrated models?
- Hydrated results are real Eloquent model instances, so standard model behavior such as casts and serialization applies once the attributes are present. The risk is attribute completeness: only the columns your SQL selects exist on the model, so accessors and $appends that depend on omitted attributes can misbehave. There is no documented reconciliation step for dirty state, the retrieved event, or missing attributes, so test those paths explicitly in your own application.
- Which relationship types can Eloquentify hydrate, including BelongsToMany pivots and morph relations?
- Any relation can be hydrated if its JSON column is named after the relation method and contains the expected keys, and the README shows nesting to arbitrary depth. BelongsToMany pivot data, MorphTo, MorphMany, and HasOneThrough support are not explicitly documented, so treat them as unverified and prototype them before relying on them. Missing primary or foreign keys in the SQL produce quietly incomplete models rather than an error, so always verify hydration against a known fixture.
- Does Eloquentify respect global scopes, soft deletes, and multi-tenant isolation?
- No. Raw SQL bypasses Eloquent global scopes entirely, so any scope-based filtering, including tenancy scoping applied at the builder or connection level, is not applied to the query you write. In a multi-tenant application this is a potential data-leak vector rather than just a correctness issue. You must replicate the scope predicates by hand in every Eloquentify query, and you should test tenant isolation explicitly.
- Is Eloquentify safe against SQL injection, and how should I bind parameters?
- Eloquentify does not generate or rewrite your SQL, it only hydrates the rows you pass in, so injection safety depends entirely on how you build the query. Use bound parameters, as in the README's DB::select call with a [$id] binding array, rather than string interpolation, and never splice request input into identifiers or ORDER BY clauses. The package ships no guardrails here, so enforce binding conventions through code review.
- Does Eloquentify actually improve performance, and how does it scale with large result sets?
- The win comes from collapsing many sequential round trips into one, which is most visible on high-latency connections or endpoints with deeply nested relations. The repository does not publish benchmarks at realistic cardinalities, and memory behavior with a large parent set is undocumented, so measure it against your own data. Keep in mind that nested json_agg subqueries can be expensive on the database side even when they save round trips.
- Is Eloquentify production-ready, and what are the alternatives?
- It is MIT licensed and small enough to fork, but it has a very small install base, a single maintainer, and limited field testing, so budget time to read the source before adopting it. Alternatives include eager loading with selective columns, query builders with joins and manual mapping, or dedicated read-model and CQRS patterns. Introducing Eloquentify behind a repository or query object keeps the change reversible if you later swap it out.