Laravel Laravel Package

Technical Evaluation

Architecture fit. fopost/fopost-laravel is a thin Laravel integration layer over the fopost/sdk PHP client: a service provider, a facade, and convenience accessors per API resource. v0.2.0 extends that pattern rather than changing it — new facade hints (media(), googleBusiness(), whatsapp(), activity) and new domain surfaces (Meta Ads depth, broadcasts, drip sequences, inbound published-article handling). For a Laravel codebase, this is the lowest-friction shape possible: composer require plus autodiscovery, no custom HTTP plumbing. The architectural fit is good if the underlying Fopost API is the system of record for marketing/broadcast channels; it is a poor fit if we only need one narrow integration, since we would inherit the whole SDK and its release cadence.

Integration feasibility. Straightforward in a standard Laravel app (8+/9+/10+ — exact constraints unverified). The package appears to assume a service-container binding and a config file for credentials; the "receive published blog articles" item implies an inbound webhook route or an event we must wire up ourselves, which is the one integration point that needs design work rather than configuration. Direct media uploads via media() mean file handling and storage credentials cross our perimeter — that should be scoped deliberately, not enabled by default.

Technical risk. Moderate, concentrated in three places:

• Pre-1.0 churn. A minor bump (0.1 → 0.2) added four new API surfaces and moved the SDK constraint from ^0.2 to ^0.3. Under semver-before-1.0 this is legitimate, but it means we cannot treat patch-grade upgrades as safe.
• Two-package coupling. fopost/sdk and the Laravel wrapper version independently. The ^0.2 → ^0.3 bump mid-release, plus a CI change to resolve the parent SDK from GitHub rather than a tagged registry artifact, raises reproducibility and version-skew risk. Pinning exact versions and committing the lockfile is mandatory.
• Single-maintainer concentration. Every PR in this release is from one author. Bus factor is 1, and the release workflow is newly introduced and therefore unproven.
• Inbound surface. Accepting published articles (and potentially delivery callbacks for broadcasts/WhatsApp) adds an internet-facing endpoint. Signature verification, replay protection, and idempotency are unknown and must be confirmed before we expose it.

Key questions.

1. What are the exact PHP and Laravel version constraints, and is Laravel 11/12 supported?
2. Is the package tested against a live or mocked Fopost API, and what is CI coverage of the new broadcasts, drip sequences, and webhook paths?
3. Does inbound blog-article delivery support HMAC/signature verification, or does it assume network-level trust?
4. Why is the parent SDK resolved from GitHub in CI rather than Packagist — is fopost/sdk 0.3 published and tagged?
5. What is the maintainer's stated support window and deprecation policy ahead of 1.0?
6. Are there rate limits, retry/backoff, and timeout defaults, or does the SDK leave them to the caller?

Integration Approach

Stack fit. Good for a Laravel-monolith or modular Laravel service where marketing automation is a secondary concern handled by an external platform. Fits cleanly as an infrastructure adapter behind our own interface — I would wrap the facade in an application-level port (MarketingChannel/BroadcastGateway) rather than injecting Fopost directly into domain code, so a future swap or SDK breakage is contained to one class.

Migration path. No prior assessment exists, so treat this as greenfield adoption rather than migration. Sequence: (1) spike in a throwaway branch — install pinned fopost/fopost-laravel:0.2.0 with fopost/sdk pinned, exercise read-only endpoints (activity, googleBusiness discovery); (2) add outbound-only writes (broadcasts, media upload) behind the adapter; (3) only then consider inbound webhooks, with our own route, signature check, and queue-based processing in front. Do not go live on webhooks and outbound sending in the same release.

Compatibility. Two axes to lock: the Laravel/PHP constraint against our runtime, and the SDK constraint against our lockfile. Because the wrapper delegates nearly everything, behaviour changes will usually arrive via fopost/sdk, not this package — so our upgrade review must diff both packages. Budget for a compatibility check on every 0.x release of either.

Sequencing and gates.

• Gate 1: spike passes on staging with real credentials; facade boots, config publishes.
• Gate 2: adapter layer merged; no direct facade references outside it.
• Gate 3: outbound features shipped with idempotency keys and retry policy we control.
• Gate 4: inbound endpoint shipped only with verified request authenticity and dead-letter handling.
• Gate 5: pin-and-review process documented and owned before any second feature team adopts the package.

Operational Impact

Maintenance. Low code volume, but non-trivial tracking effort: two independently versioned 0.x packages, frequent releases (this one carries 14 PRs), and no LTS signal. Realistic estimate is a half-day review per upstream minor release plus a dependency-bump PR cadence. The adapter layer is what keeps this cheap; without it, every SDK bump becomes a codebase-wide grep.

Support. Single maintainer, community-supported, no commercial SLA evident. Assume GitHub-issue-level support and plan internal ownership of any production incident. If the marketing channel is revenue-affecting, we need either a vendor support agreement with Fopost (the platform, not the package) or an internal fallback path for sending.

Scaling. The package is a client, so scaling is dominated by the upstream API's rate limits and our own queueing discipline. Broadcasts and drip sequences are inherently batch-shaped — these must run through Laravel queues with rate limiting and per-tenant throttles, never synchronously in a request. Media uploads should be streamed/queued rather than buffered. Confirm payload size limits before designing the upload path.

Failure modes.

• Upstream API change or deprecation — silent breakage in a 0.x SDK; mitigate with pinned versions and a contract test suite we own.
• Version skew between wrapper and SDK — composer update pulls a 0.3 SDK with a 0.2 wrapper; mitigate with exact pins and lockfile review.
• Unverified dependency resolution — a CI/build path pulling the SDK from GitHub is not reproducible; publish and consume tagged artifacts.
• Partial broadcast/drip execution — no idempotency means duplicate sends; we must own dedupe keys and record send state on our side.
• Inbound webhook abuse or replay — unauthenticated or unverified delivery could inject bogus "published" content; require signature checks and reject unverified payloads.
• Bus factor — package abandoned or maintainer unavailable; the adapter layer plus our own thin HTTP fallback is the exit plan.

Ramp-up. A Laravel developer familiar with facades and queued jobs is productive on outbound features in under a day — the README examples and the new per-resource facade hints keep the API discoverable. The real learning curve is domain, not code: understanding channels (WhatsApp, Google Business, Meta Ads), broadcast vs. drip-sequence semantics, and the media lifecycle. Budget one to two days of domain onboarding and half a day of platform/credentials setup. Inbound handling and the adapter contract need a written runbook before handover.