Hasura Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing to establish is that this is a Symfony bundle, not a Laravel package — the name, namespace, and the hasura-extra project family (which ships hasura-extra/action, hasura-extra/event, hasura-extra/hasura-client, and a separate Laravel sibling) all point to a Symfony-first design. A bundle is a DI-container plugin: it registers services, config trees, and routes through Symfony's kernel. Laravel has no equivalent extension point, so there is no PackageManifest auto-discovery path here. In a Laravel codebase the artifact you would actually want, if any, is hasura-extra/laravel — and it inherits the same abandonment profile. The bundle's conceptual value is real: it standardizes the Hasura HTTP contracts that are genuinely fiddly to hand-roll — action request envelopes (action.name, input, session_variables, request_query), the response/error shape Hasura expects (extensions.code, extensions.path), event-trigger payload parsing, and client wrappers for Hasura's metadata/API. That is roughly 150–300 lines of glue per integration. The question is whether we buy that glue at the cost of an unmaintained dependency.

Integration feasibility. Low, and worse in Laravel than in Symfony. Three compounding problems: (1) no auto-discovery — the bundle's services must be manually re-registered or bypassed; (2) dependency resolution risk — a Symfony bundle pulls symfony/http-kernel, symfony/dependency-injection, and symfony/config, all of which Laravel pins to its own supported versions, so composer require may fail outright or force a downgrade of the framework; (3) PHP 8.1+/8.2+ compatibility remains unverified. The v1.1.0 release does not touch any of this: the sole changelog entry ("split remote schema permissions when export metadata") is a metadata-serialization change with no stated constraint, framework-support, or dependency-graph updates. A 1–2 day install spike still answers feasibility definitively and should precede any design work.

Technical risk. High and concentrated in lifecycle, not code quality. Prior signals were near-total: 6 stars, 0 dependents, single-maintainer bus factor, and a release history that had been dormant since 2021-10-27. v1.1.0 is the first new release since then, which is a genuine but thin positive signal — it revises the "last release" fact and suggests the codebase is not fully frozen. It does not revise the risk rating: a single one-line changelog is not evidence of a maintenance commitment, a supported-version policy, a security disclosure channel, or CVE response. There is also upstream drift: Hasura's Actions/Event Triggers model belongs to the v2 line, and Hasura's v3/DDN architecture reshapes how custom business logic is wired. Adopting a 2021-era adapter locks the integration to a contract that Hasura itself has moved past.

Key questions. What PHP and Laravel versions are actually in the support matrix — and did v1.1.0 change it? Does the release indicate resumed maintenance or a one-off commit, and is there a stated support window? Was the equivalent release cut for hasura-extra/laravel and the sibling libraries, or is this bundle now ahead of them? Which Hasura version are we targeting — v2 or v3? What is our real exposure if the action error contract changes? And critically: who owns a fork if we adopt?

Integration Approach

Stack fit. Poor as-is. In Laravel, the bundle's responsibilities map cleanly onto first-class framework primitives: action handlers → controllers with FormRequest validation; event triggers → queued jobs; webhook secret verification → middleware; Hasura client calls → the existing Http facade. Adopting a Symfony bundle to reach those primitives inverts the framework's grain and creates a maintenance surface we do not control. Note that v1.1.0 lands in the metadata-export area — a code path we would not exercise at all in a Laravel action/event integration, so the release improves none of the surfaces we actually care about.

Migration path. Prefer concept transfer over code acquisition. Read the bundle (and its sibling libraries) as a specification for the Hasura contracts, then implement a thin internal adapter in Laravel — a small Hasura package with an action request DTO, an error-response builder matching Hasura's extensions shape, an event-payload parser, and a signed-webhook middleware. If a fork is genuinely warranted, fork under our own vendor namespace with a pinned PHP constraint, add CI across our supported Laravel versions, and document the fork in the ADR. If we later need metadata tooling, evaluate v1.1.0's remote-schema permission splitting on its own merits as a CLI-level concern, separate from the runtime adapter.

Compatibility. Treat as unknown until spiked. The Symfony component version collisions with Laravel's own pinned dependencies are the most likely hard blocker; PHP 8.1+ deprecation noise is the second. v1.1.0 carries no compatibility claims, so it neither resolves nor worsens this. Pin the runtime explicitly and run a matrix against each Laravel version in our support window before committing.

Sequencing. Phase 0: 1–2 day install spike against our actual composer.json to determine whether the dependency graph resolves at all. Phase 1: if it resolves, prototype one action handler and one event trigger behind a feature flag. Phase 2: if the prototype holds, wrap it in an internal adapter so the third-party surface is a single seam. If the spike fails — still the likely outcome — skip directly to the in-house adapter and treat the bundle as reference documentation only. In parallel, set a lightweight watch on release cadence: two or more substantive releases in the next two quarters, with CI and a version-support statement, would justify re-running this evaluation.

Operational Impact

Maintenance. Archival-adjacent software means we own it the moment we install it. v1.1.0 shows the repo is not fully dead, but a single narrow feature commit does not shift the ownership burden: budget for a fork, a CI matrix, and a named owner. Without that, the dependency decays silently until a PHP upgrade breaks the build.

Support. Effectively none. There is no escalation path, no issue triage, and near-zero community footprint (0 dependents) means no Stack Overflow corpus and no peer experience to draw on. Ramp-up cost is "read the source," which is tractable here given the small code surface but should be priced in.

Scaling. The library is not the scaling constraint — it is synchronous HTTP handling for action webhooks and payload parsing for event triggers. Scaling is a property of our app tier and queue workers. Event triggers do impose Hasura's retry-with-backoff semantics, so handlers must be idempotent regardless of what the library offers; verify whether dedupe keys are provided or whether we implement them.

Failure modes. Four to design against: (1) auth spoofing — if x-hasura-* session variables are trusted from arbitrary clients rather than enforced via Hasura's webhook secret, that is a privilege-escalation hole; the secret check is non-negotiable and must not be delegated to an unmaintained library. (2) Error-contract mismatch — malformed action error responses surface to GraphQL clients as opaque 500s, degrading debuggability. (3) Duplicate side effects from event-trigger retries. (4) Timeouts — action handlers exceeding Hasura's default budget fail the parent GraphQL operation, so handler latency becomes a GraphQL availability concern. Metadata-export changes carry their own failure mode (malformed/partial metadata applied against a live project), but that is out of scope for a Laravel runtime adapter.

Recommendation. Do not adopt. Score is unchanged: framework-mismatched, unmaintained in any meaningful sense, zero adoption signal. v1.1.0 is a single metadata-export fix that touches none of the surfaces relevant to a Laravel integration and supplies no support, compatibility, or security commitments — it is a watch-list data point, not a reversal. Use the bundle as a reference implementation for Hasura's wire contracts and build the ~200-line Laravel adapter we control.