Hasura Bundle Laravel Package

Product Decisions This Supports

• Architecture decision: Hasura-first vs. PHP-first API. Adopting Hasura as the GraphQL layer over Postgres pushes custom business logic (validations, third-party calls, multi-step writes) out of your PHP app and into Actions; async side effects into Event Triggers; and auth into webhooks. This package is the glue layer for exactly that topology, so evaluating it forces the real question: do we want a GraphQL BFF owned by Hasura, or a Laravel/Symfony API that Hasura simply calls?
• Build vs. buy for integration boilerplate. What the bundle actually provides is thin and reproducible: action handler base classes, event handler plumbing, session-variable/claims helpers, and request/response contracts. That is roughly 200–500 lines of in-house code. The decision is "fork/vendor a dead package" vs. "write and own a 2–3 day internal adapter" — and the internal adapter almost always wins on this evidence.
• Feature scoping for a Hasura integration epic. If Hasura is on the roadmap, this repo is a useful requirements checklist: which action input/output types we must support, how we validate admin-secret headers, how we pass x-hasura-* session variables into handlers, and how event payloads get deserialized. Use it to size the work, not to deliver it.
• Roadmap signal on ecosystem maturity. Six stars, zero dependents, archived since ~2021, no release in four years — that is the market telling you the PHP↔Hasura glue niche is unserved. Budget for owning this layer entirely, and do not plan a roadmap that assumes community tooling will absorb the maintenance.
• Vendor/tech-debt triage. If it is already in the codebase, this assessment supports a deprecation ticket with a concrete migration path (extract to an internal app/Hasura/ namespace) rather than an indefinite "leave it alone."

When to Consider This Package

Consider only as a reference implementation, not a runtime dependency. Concretely, that means: you are on Symfony (it is a Symfony Kernel bundle — hasura-extra/hasura-bundle will not install usefully into a Laravel app, despite the Laravel/PHP framing in the brief), you already operate Hasura in production, and you want a working example of action/event handler wiring to read before writing your own.

Look elsewhere — or build — if any of the following is true:

• You are on Laravel. The package targets Symfony's bundle/service-container model. There is no Laravel service provider, no facade, no published config. This is the decisive disqualifier for a Laravel stack.
• You need a maintained dependency. Archived repo, dead issue tracker, last release 2021-10-27, no security patch path, no maintainer to escalate to. Anything on the request path of production traffic is out.
• You need current Hasura features. Post-2021 Hasura capabilities (newer permission/session semantics, Hasura v3/DDN, improved event trigger delivery guarantees, JWT/header changes) are not represented.
• You need modern PHP support. No guarantees for PHP 8.2/8.3+, no compatibility matrix, no CI signal.
• Adoption breadth matters to you as a risk proxy. Zero dependents means zero downstream validation — you would be the only known user.

Preferred alternatives, in order: hand-rolled controllers plus Hasura's own action/event-trigger documentation and CLI codegen; an internal shared package if multiple services need it; the sibling hasura-extra/* libraries only if you have independently verified one is maintained (this one is not).

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated hasura-extra/hasura-bundle as a way to connect our PHP backend to Hasura's Actions and Event Triggers. Recommendation: do not adopt it. It is archived, has had no release since October 2021, has essentially no user base, and is built for Symfony rather than our Laravel stack — which means no security patching, no support, and no upgrade path. The functionality it offers is small and well-documented, so if Hasura integration stays on the roadmap we can replace it with roughly two to three days of in-house code that we fully own and can maintain.

To engineering (the ask): Treat the repo as a pattern reference, not a dependency. Mine it for three things — the action handler request/response contract, the admin-secret authentication check, and how x-hasura-* session variables are surfaced to handlers — then implement those as a small internal module behind a clear interface. Keep the interface narrow so a future Hasura version bump touches one place. If it is already in the codebase, open a deprecation ticket with that extraction as the exit criterion.

Risk framing to state plainly: an archived, unmaintained package in the request path is an unowned dependency on the critical path. The cost of writing it ourselves is days; the cost of a silent breakage in action handling or auth is an outage plus an unplanned migration under pressure.