Laravel Graphql Utils Laravel Package

Product Decisions This Supports

• Reliability of the GraphQL surface. This release closes an input-validation gap where malformed request bodies (JSON or multipart) that look like a batch — e.g. {"query":"…","0":"x"} — were passed through to webonyx/graphql-php, which parsed them as a batch and then threw a TypeError. Those become 500s, error-budget burn, and noisy alerts rather than clean 4xx responses. Patch-level upgrade, directly reduces unhandled-exception rate on the API edge.
• Build vs. buy on request parsing. Reinforces the case for owning GraphQL transport concerns (multipart uploads, batching, body normalization) via a maintained dependency instead of a hand-rolled middleware. The vendor is actively hardening the parser against adversarial/edge-case payloads — the kind of work an internal team would only do after an incident.
• Security & input-hardening roadmap item. Malformed-body handling is the same class of work as schema depth limits, query cost analysis, and payload size caps. This release can be slotted into an existing hardening epic as a no-cost win rather than a standalone initiative.
• Use cases affected. Anything accepting GraphQL file uploads (multipart spec) or batched operations — mobile clients that batch, admin tooling, third-party integrations. If none of those are enabled, the practical impact is near zero and this is routine maintenance.
• Not a differentiator. No new capability, no API change. It is a correctness/robustness fix; treat it as hygiene, not as roadmap input.

When to Consider This Package

Adopt when:

• You run Lighthouse (or another Laravel GraphQL stack) on top of webonyx/graphql-php and need correct handling of multipart request bodies (file uploads) and/or batched operations — the two transport shapes this package exists to normalize.
• You want that normalization maintained upstream rather than reimplemented, and you are willing to track a small, low-churn dependency whose version must stay aligned with your webonyx/graphql-php constraint.
• You accept patch-level upgrades on a regular cadence; the value here accrues from staying current, not from a one-time adoption.

Look elsewhere / skip when:

• Your API is REST-only, or your GraphQL endpoint deliberately disables batching and uploads at the edge — you get the dependency cost without the benefit.
• You are pinned to an incompatible webonyx/graphql-php major and cannot upgrade; check the constraint before planning the bump.
• You need a supported SLA, CVE process, or commercial backing — this is community-maintained. For a regulated or high-assurance surface, plan for internal review of the parsing path regardless of what you adopt.
• You would rather terminate malformed bodies at the gateway/WAF and keep the app layer minimal — a legitimate architecture, but it does not remove the need for defensive parsing behind it.

How to Pitch It (Stakeholders)

For executives: A small, free patch upgrade to a utility library that sits in front of our GraphQL API. It fixes a case where a malformed client request could crash the request handler and return a server error instead of a clean rejection. No new features, no migration, no user-visible change — it reduces a class of avoidable 500s and the on-call noise that comes with them. Cost: a routine dependency bump.

For engineering: laragraph/utils v2.3.2 rejects JSON and multipart bodies that webonyx/graphql-php would otherwise parse as a batch containing non-object entries (e.g. {"query":"…","0":"x"}), preventing a TypeError. Patch release, no API or behavior change for well-formed requests; malformed-but-batch-shaped payloads now fail fast rather than reaching the executor. Upgrade is a composer bump with no code changes; validate that your webonyx/graphql-php constraint resolves, then confirm the multipart-upload and batched-query integration tests still pass. Worth folding into the current input-hardening work rather than a dedicated ticket.