Facebook Laravel Package

Product Decisions This Supports

• Channel expansion for user re-engagement. If the product already has Facebook Login, this package lets you add Facebook as a delivery target inside Laravel's existing Notification/Notifiable system with roughly one class of message-building code and one via() entry. That makes it a cheap experiment: “does a Facebook notification channel move retention for our FB-linked cohort?”
• Build vs. buy (adopt vs. write in-house). The package is thin middleware over the Graph API — a channel class, a message DTO, and a service provider. Adopting it saves an estimated 1–3 dev-days over hand-rolling the same thing. The 0.3.0 release materially improves the maintenance signal — Laravel 9 support plus two community-contributed feature PRs from a first-time contributor — but with 152 stars and no downstream dependents on record, it is still a single-maintainer project with no SLA. Treat it as vendored source you will maintain, not as a maintained upstream.
• Roadmap sequencing. This is not a channel to build strategy on. It is best positioned after email/push/SMS/in-app are healthy, and only if the FB-linked share of MAU justifies the surface area. 0.3.0 removes the Laravel 9 blocker, so the remaining gate is cohort size and Meta eligibility, not framework version. Decision input: measure the % of active users who authenticated via Facebook and still hold a valid token before scoping work.
• Use-case triage. Realistic fits: gaming/Canvas-style apps that still qualify for user notifications, social publishing tools that notify page admins, and internal alerting for teams whose workflow lives in Facebook. The new string-payload button support and image aspect-ratio helper expand what a single notification bubble can carry — richer CTAs (URL or postback) and correctly proportioned hero images — which modestly widens the fit for marketing-adjacent notification copy without turning this into a campaign tool. Poor fits: consumer SaaS whose audience is email-first.
• Risk decisions made explicit rather than implicit. Adopting this forces the team to make platform-risk decisions up front: Meta app review and permission scope, short-lived user token refresh, Graph API version pinning and annual deprecation churn, and a fallback channel when delivery fails.

When to Consider This Package

Consider adoption when all of the following hold:

• You are on Laravel 9 (now explicitly supported as of 0.3.0) — or on Laravel 8, which the channel's history still covers. Laravel 10+ is not verified by this release; if you are there, budget to patch constraints and test yourself.
• You already have Facebook Login and persist user IDs plus long-lived tokens.
• You have confirmed against current Meta documentation and app review that your app category is still permitted to send user notifications — this endpoint has been progressively restricted, and eligibility remains the single biggest unknown. A framework-support release does not change platform policy.
• You are comfortable forking or pinning the package and owning it, including a test suite against a mocked Graph client.
• Facebook is one of several channels and a failed send degrades gracefully to email or push.

Look elsewhere when:

• You actually want Messenger bot messaging. That is a different API surface; use a Messenger-specific channel or Botman — this package is not it.
• You want marketing broadcasts or Page publishing. Use the Graph Pages/Marketing APIs or a commercial provider; a notification channel is the wrong primitive for campaigns, and richer buttons do not change that.
• You need support, SLAs, delivery analytics, or multi-provider failover. A commercial multichannel provider (or self-hosted Novu/Courier-style layer) is a better fit and removes the Graph API version treadmill.
• The notification is on a critical path. No dependents and a low-frequency release cadence is a poor foundation for anything a customer contract depends on.
• You have no Facebook Login. Without user IDs and tokens the package has nothing to talk to.
• The FB-linked cohort is a small slice of MAU. Below a meaningful threshold, the maintenance cost of a deprecated-platform integration exceeds the reach gained.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible, low-cost addition to our notification stack — one MIT-licensed dependency that lets us reach users who signed in with Facebook, using the notification infrastructure we already have. It is not a strategic bet. The project shipped its first release in roughly two years (0.3.0), which adds Laravel 9 support and two community-contributed message-formatting features; that is a genuine improvement in maintenance health but not evidence of a support commitment. Meta has been steadily narrowing who may send user notifications, so the value is concentrated in a specific cohort and the lifetime of the channel is outside our control. Recommendation: approve a one-developer-day spike to confirm eligibility and measure the addressable cohort, with a go/no-go gate; if it proceeds, fund a fork we own rather than treating upstream as a supplier.

To engineering: The integration is deliberately boring — a channel class implementing send(), a message object, and a service provider, plugged into Laravel's existing via() contract so it is swappable and testable in isolation. 0.3.0 clears the Laravel 9 constraint and adds string payloads for buttons plus an image aspect-ratio helper, so the message builder now covers rich CTA buttons and correctly sized hero images without custom templating. This is additive, not breaking — expect a clean bump from 0.2.x. The real work is not the package: it is token storage and refresh, Graph API version pinning with a deprecation calendar, app review and permission scoping with Meta, and a graceful fallback when delivery fails. Assume you will fork, add contract tests against a mocked Graph client, and own upgrades. Budget roughly one day for the spike plus two to three days to productionize, and keep the channel behind our notification abstraction so removing it is a config change, not a refactor.