Facebook Poster Laravel Package

Product Decisions This Supports

• Build vs. buy for Facebook Page distribution: This package reduces a Graph API integration to a Laravel notification — a notification class, a FacebookPosterMessage, and a Page token in config/services.php. The build side of that trade is only defensible if you already own a social-publishing layer (Buffer, Hootsuite, a marketing automation platform) that must remain the single path to market. If not, buy.
• Scoping the "social" feature set: It posts to a Facebook Page only — text, links, images. It is not inbox management, insights/analytics, ad publishing, comment moderation, scheduling, or user-timeline posting. Any roadmap item that silently assumes those capabilities is mis-scoped and needs its own evaluation.
• Platform sequencing: Release 6.2.0 drops Laravel 10 and PHP 8.1, so the floor is now Laravel 11 / PHP 8.2. Adoption is therefore coupled to the framework modernization workstream — a sequencing and priority decision, not an isolated ticket. Greenfield services adopt cleanly; legacy services should be scoped alongside their upgrade, not ahead of it.
• Roadmap confidence for "announce things automatically": For products with a real but modest publishing need — changelogs, release announcements, marketing pushes, internal "we shipped X" broadcasts — the incremental cost is near zero and the dependency is thin and single-purpose. For products with multi-channel ambitions, this is a component of a larger feature, never the feature itself.
• Utility vs. platform classification: Active release cadence (Feb 2025) and maintainers willing to cut a breaking platform bump are reasonable maintenance signals — but ~141 stars, zero listed dependents, and a single small channel mean this is a utility dependency, not a de-risked platform investment. Budget for a future forced platform jump and for a fork-if-abandoned fallback.
• Operational ownership as a product commitment: Posting to a Page requires a Meta app, a Page, a long-lived Page access token with rotation, and (beyond basic posting) app review. Those sit with marketing/social owners, not engineering. That is a product-operations line item in the plan, not a backlog afterthought.
• Risk appetite for revenue-critical posting: If automatic publishing is load-bearing, wrapping it behind an internal adapter — or making manual posting the fallback — is a product decision about acceptable quiet failure, not just an engineering preference.

When to Consider This Package

Consider it when:

• The application is already on Laravel 11+ / PHP 8.2+, or that upgrade is committed and funded this cycle.
• The requirement is narrow and well-defined: post text/links/images to one Facebook Page on events the app already models.
• You want the post routed through Laravel's notification system so queuing, retries, and failure handling are inherited rather than hand-rolled around a Graph API call.
• Someone is named as owner of the Meta app, Page, token lifecycle, and content policy for automated posts.
• The team can absorb periodic forced platform bumps as routine maintenance and pins the constraint explicitly (e.g. ^6.2).

Look elsewhere — or pin the previous major — when:

• The service is locked to Laravel 10 or PHP 8.1 with no near-term upgrade path; 6.2.0 will not install, and staying behind forgoes future fixes.
• You need multi-channel publishing, multi-Page, scheduling, approvals, analytics, or moderation — building a social layer on this means re-evaluating almost immediately.
• Publishing is revenue-critical and a single-maintainer, low-adoption dependency is unacceptable — wrap it in your own adapter, vendor the code, or route through an owned marketing platform.
• You need a long, predictable support window with no forced platform jumps (regulated, on-prem, slow-moving customer upgrade cycles).

Verify before committing: the exact composer.json support matrix, the token flow and rotation procedure, the targeted Graph API version and its deprecation posture, whether the prior major still receives fixes, and — critically — whether rejected posts, expired tokens, and rate limits fail loudly into your alerting. Silent non-publishing is a product failure mode, not just an engineering bug.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed adapter that lets our Laravel app publish to a Facebook Page through the notification system we already run — roughly a day of integration once the platform baseline is in place. It buys a real distribution channel without us building or maintaining a Graph API integration. It is deliberately narrow: one Page, text/links/images, no analytics, scheduling, or moderation. The one gating fact is that the current release requires Laravel 11 and PHP 8.2, so where that upgrade is already planned the cost is near zero, and where it is not, adoption should ride inside that upgrade's business case rather than appear as a separate line item. Risk is low but real — a single-maintainer, low-adoption dependency — so treat it as a utility, not a strategic bet, keep a thin internal adapter as the fallback, and note that no new spend is implied. The decision is sequencing and scope, not budget.

To engineering: 6.2.0 is effectively a breaking change — it drops Laravel 10 and PHP 8.1, so the floor is Laravel 11 / PHP 8.2. Pin ^6.2, add the baseline to CI, and run a composer why-not sweep before any update. Integration is a notification class plus a FacebookPosterMessage, with the Page token in secret storage and services.php; dispatch as queued notifications so retries and backoff are inherited. Confine the package behind one internal adapter class so a fork or swap is a single-file change. Validate the failure surface deliberately — revoke a sandbox token and confirm the job fails loudly, retries per policy, and alerts. Re-diff the published config against the stub after every minor bump, since renamed keys surface at runtime, not install time. For services that cannot move yet, pin the last compatible prior major, record the reason and a review date, and flag it in the next dependency review.