Graphql Orm Laravel Package

Getting Started

This release (v5.2.0) is additive — no breaking changes, no deprecations — so upgrading is a composer update away and the payoff is entirely in the profiler. Start there.

1. Update the package, then open any GraphQL request in your dev environment with the web profiler enabled. There is no new config to publish: the new panels appear on the existing GraphQL profiler panel.
2. First thing to look at is the Entities tab. It lists the mapped entities as the bundle maps them — root field, identifier, repository, each property with its GraphQL field, plus relation target and fetch mode. Entities actually read by the current request are listed first. This is the fastest way to answer "what is this GraphQL type actually backed by?" without grepping for a repository class.
3. First use case: a slow query. Open the query's Hydration tab to see whether the time is spent in the database or converting rows into PHP objects — two very different fixes.

Note for Laravel developers: this is a Symfony bundle, so the profiler means symfony/web-profiler-bundle, not Telescope or Debugbar. The mental model (a dev-only request inspector) transfers; the wiring does not.

Implementation Patterns

Triage slow queries before optimising. The duration bar for each query now has a grey segment for hydration, and the Hydration metric excludes network time. Use it to split a 400 ms query into "SQL is slow" vs "we are hydrating 5,000 rows into entities". Only the first is fixed with indexes and findBy; the second is fixed by paginating or selecting fewer fields.

Hunt the find() fan-out. When several queries in one request are all a find() on the same entity, the profiler now surfaces the equivalent findBy() that would load them in one go, keyed on the identifier of the entity. When the profiler is enabled, GraphqlQueryTrace::$identifierProperty names that identifier — set it to your natural identifier if it is not id. The pattern is: read the profiler's suggestion, replace the per-item resolver calls with a single batched load, re-profile to confirm the query count dropped.

Use the "caller" line to find lazy-loading. Relation loads triggered on first access now resolve to the source line — {{ task.assignee }} in task/index.html.twig:25 — instead of an entity's __toString() or a file inside the Twig cache. If you have ever chased a stray query and landed in var/cache/dev/twig/, this is the fix. Workflow: profile a page, look at queries you did not write explicitly, jump straight to the template line, and decide whether to eager-load via the query or accept the lazy fetch.

Read the query highlighting as a syntax check. Keywords, fields, arguments, types, variables, strings, numbers and masked values are colour-coded in the profiler theme. It is cosmetic, but it makes a mis-nested argument or a variable that silently resolved to an empty string visibly wrong at a glance.

Gotchas and Tips

• Profiler-only features cost nothing in production but also help nothing there. Every item in this release is conditional on the profiler being enabled. Do not ship a debugging strategy that depends on them.
• GraphqlQueryTrace::$identifierProperty must be set for the findBy() hint to be meaningful. Leave it unset and the suggestion has no identifier to key on. Set it once, globally, wherever you configure the profiler.
• Hydration time is measured apart from the network. That is exactly what makes it useful, and exactly what makes it easy to misread: hydration + network + database will not simply add up to the reported query duration you see elsewhere. Compare like with like.
• The caller change is a behaviour change in the profiler, not in your application. Stack traces in the profiler will no longer include entity methods as frames for lazy-loaded relations. If you had learned to read those frames, recalibrate — the new line is more accurate, but it is different.
• The findBy() suggestion is a hint, not a refactor. It is detected from repeated identical find() shapes; batched loading can change result ordering and empty-result semantics, so verify behaviour, not just query count.
• Masked values are masked in the highlight only. Do not treat the profiler's colouring as a redaction guarantee — sensitive data handling still belongs in your schema and resolvers.