Larahook Laravel Package

Technical Evaluation

Architecture fit

• Larahook is a Laravel-native package (service provider + auto-discovery, publishable config and migrations, queue-backed delivery). It slots into the "outbound webhook fan-out" concern rather than competing with the app's domain architecture — a low-coupling addition.
• Appropriate when the platform needs to notify external consumers (partner integrations, tenant endpoints) of internal events. It is not a substitute for an event bus or internal messaging layer; treat it as an egress adapter.
• Fits standard Laravel deployment topologies (single app + queue workers). Assumes a real queue backend; synchronous delivery would be a design smell in production.

Integration feasibility

• 1.4.3 is a patch release whose only change is a widened framework constraint for Laravel 13 (#13). No API surface change, no migration change, no config change signalled.
• Integration cost is low-to-moderate: composer require, publish config/migrations, define which domain events map to webhook payloads, wire signing secrets, provision queue capacity, expose retry/dead-letter visibility to support staff.
• The real effort is not the package install — it is the surrounding product surface: subscription management (who receives which events), secret rotation, delivery logs, and replay tooling.

Technical risk

• Low immediate risk: patch-level version, single-line changelog, additive compatibility only.
• Vendor concentration risk: single-maintainer/small-team package (CoInvestor). Release cadence is modest (1.x line), so Laravel major-version support arrives reactively rather than ahead of the framework. This release is a good signal — support landed — but it confirms the dependency is on the maintainer's timeline, not ours.
• Constraint-drift risk: widening for Laravel 13 can silently drop older framework support. Must diff composer.json between 1.4.2 and 1.4.3 rather than trusting the changelog.
• Egress risk: webhook delivery touches third-party endpoints. Timeout, retry, and backoff defaults become our production behaviour; if they are not configurable, that is a material gap.
• Framework 13 readiness risk: the release makes the package installable on Laravel 13, not necessarily validated on it. Absence of a CI matrix entry or PHP-version statement is a real question.

Key questions

1. Did 1.4.3 narrow the supported illuminate/* or PHP range, and does that affect our current Laravel/PHP pin?
2. Is Laravel 13 support CI-tested, and against which PHP versions?
3. What are the default timeout, retry count, and backoff strategy — and are they configurable per endpoint?
4. Is delivery signing (HMAC/shared secret) supported with rotation of multiple active secrets?
5. Is there an idempotency/delivery-ID mechanism so consumers can dedupe?
6. What is the persistence model for delivery attempts, and is there a pruning/retention story?
7. Who is the maintainer-of-record, and is there a published security policy?

Integration Approach

Stack fit

• Laravel 11/12 today, Laravel 13 available on 1.4.3. PHP constraint to be confirmed from composer.json.
• Requires a durable queue driver (Redis, SQS, or database) plus supervised workers; database queue is acceptable for low volume but will contend with application writes at scale.
• Standard Laravel conventions (config publish, migrations, auto-discovery) mean no bespoke bootstrap work and no framework fork.

Migration path

• Greenfield: install 1.4.3 directly, publish assets, map domain events, ship behind a feature flag to one internal/partner endpoint first.
• From hand-rolled webhook code: run in parallel — dual-send to the new pipeline while the legacy sender remains authoritative — until delivery logs match for a defined window (suggest 2 weeks or N deliveries), then decommission the legacy path.
• From an alternative package (e.g. spatie/laravel-webhook-server): the data models differ, so expect to write a one-off backfill of endpoint/subscription records. Do not attempt in-place table reuse; stand up new tables alongside.
• Rollback: patch-level bumps roll back by constraint pin alone; because 1.4.3 adds no migrations, reverting is low-friction. Confirm this before adopting.

Compatibility

• Verify the full matrix before committing: our Laravel version, PHP version, queue driver, and DB engine (JSON column usage, index lengths on MySQL).
• Check transitive dependency deltas in the 1.4.2→1.4.3 diff; a widened framework constraint can pull a newer illuminate/support than the rest of the app is prepared for.
• Confirm no conflict with existing packages that also register webhook/HTTP client middleware.

Sequencing

1. Diff composer.json and CHANGELOG between 1.4.2 and 1.4.3; confirm constraint ranges and CI coverage.
2. Spike in a sandbox: install, publish, deliver to a request-bin endpoint, verify signature scheme and retry behaviour empirically.
3. Build the product surface (subscription management, secret rotation, delivery log UI, replay) — this is the bulk of the work and should not be discovered late.
4. Provision queue capacity and worker isolation; webhook egress should not share a worker pool with critical internal jobs.
5. Pilot with one internal consumer; instrument success rate, p95 delivery latency, and retry volume.
6. Progressive rollout by event type, with a kill switch per event type.
7. Document runbooks (backlog drain, stuck endpoint quarantine, secret rotation) before GA.

Operational Impact

Maintenance

• Low ongoing code maintenance; the package is a thin adapter. The recurring cost is dependency hygiene: a framework major release each year means a constraint bump, a regression pass, and a scheduling dependency on the maintainer.
• Recommend pinning to ~1.4.0 (patch-and-minor within 1.4) and reviewing on a quarterly cadence rather than tracking dev/*.
• Contingency: because the package is small and single-purpose, forking is a credible fallback. Budget a nominal reserve (roughly one engineer-week per year) for the possibility of vendoring a fork if upstream goes dormant mid-framework-cycle.

Support

• No commercial SLA. Support is GitHub-issue-based, best-effort. Internal tier-1/tier-2 must own the operational layer (endpoint misconfiguration, secret rotation, replay) without escalating upstream.
• Support burden concentrates on consumer-side failures ("we didn't get the webhook"), so delivery log observability is not optional — it is the primary support tool.

Scaling

• Delivery throughput is bounded by queue worker concurrency, not by the package. Size workers against peak event volume × fan-out (subscribers per event).
• Fan-out amplification is the main scaling hazard: one domain event with 50 subscribers becomes 50 jobs. Enforce a per-event subscriber cap or batch at the producer.
• Delivery-attempt tables grow linearly with retries and are the most likely source of DB bloat. Plan retention (e.g. 30–90 days hot, archive beyond) from day one.
• Slow or dead consumer endpoints consume worker time up to the timeout; aggressive per-request timeouts and a circuit-breaker/quarantine for repeatedly failing endpoints are required to protect the shared pool.

Failure modes

• Retry storm: a consumer outage plus automatic retries can saturate the queue. Mitigate with exponential backoff, capped retry counts, and per-endpoint circuit breaking.
• Head-of-line blocking: webhook jobs sharing a queue with transactional jobs will delay critical work. Isolate queues.
• Duplicate delivery: at-least-once semantics are typical; consumers must dedupe. Publish the delivery ID in the payload and document receiver expectations.
• Signature mismatch after rotation: supporting an overlap window with multiple active secrets is essential; otherwise rotation becomes an outage for every consumer simultaneously.
• Silent drop on constraint drift: an unnoticed Laravel upgrade outrunning the package constraint can fail at install time (loud) or, worse, at runtime behind a version guard (quiet). Pin and test.
• Unvalidated framework 13 path: if CI does not cover it, treat 1.4.3-on-Laravel-13 as unsupported internally until our own smoke tests pass.

Ramp-up

• Engineering: roughly 1–2 days for a Laravel-fluent engineer to install, publish, and deliver a signed webhook end-to-end; 1–2 weeks to build the product surface (subscriptions, logs, replay) properly.
• Operations/Support: half a day of runbook training — reading delivery logs, quarantining an endpoint, rotating a secret, draining a backlog.
• Consumer-facing documentation (payload schemas, signature verification samples in at least two languages, retry policy, dedupe guidance) is the largest and most frequently underestimated deliverable; assign an explicit owner.
• Assessment delta: 1.4.3 is a compatible, non-breaking compatibility release. It removes a near-term blocker (Laravel 13 adoption) and confirms the package is actively maintained, but it does not change the integration shape, risk profile, or effort estimates above. Recommend proceeding with the sandbox spike, gated on the composer.json constraint diff and confirmation of Laravel 13 CI coverage.