Awspushbundle Laravel Package

Product Decisions This Supports

• Build vs. buy for push delivery. This bundle is the "thin buy" option: instead of building and maintaining per-platform device-token lifecycle, APNs/FCM credential rotation, and retry logic, you adopt AWS SNS as the delivery substrate and this bundle as a ~small Symfony integration layer. It supports a decision to not own push infrastructure.
• Feature scoping for notifications. It supports a scoped launch of one-to-many transactional push (order updates, alerts, reminders) across iOS, Android, and web from a single server-side API call. It explicitly does not solve campaign management, templating, scheduling, A/B testing, or delivery analytics — those remain separate roadmap items if you need them.
• Platform coverage roadmap. Because SNS fans out to APNs, FCM, and web push behind one interface, this supports launching all three channels in one increment rather than sequencing iOS → Android → web.
• Vendor-lock and cost modelling. Adopting this makes AWS an explicit dependency for a user-facing channel. That's a decision worth surfacing early — SNS publish pricing is low (order of $0.50 per million mobile push publishes) but the lock-in is architectural, not just commercial.
• Buyer/segment fit. Relevant if your product is a Symfony application serving a mobile or web client where notifications are a supporting feature, not the core value proposition. It is a poor fit if notifications are the product.
• Ecosystem signal for a "reuse" decision. 40 stars, zero known dependents, and a composite score of 1.22 are weak adoption signals. This package is best framed as "a small, readable integration we could fork in a day" rather than "an established dependency we inherit."

When to Consider This Package

Adopt when:

• The application is Symfony (this is a Symfony Bundle, not a Laravel package — for a Laravel codebase, treat this as reference implementation only and prefer laravel-notification-channels/sns or a direct AWS SDK integration behind Laravel's Notification system).
• You are already on AWS and comfortable with SNS as the push broker, or you want a single abstraction for APNs + FCM + web push.
• Your push needs are transactional and modest in volume — no campaign tooling, no per-user send-time optimization, no rich analytics.
• You want device-token/endpoint management handled for you (SNS platform endpoints) rather than building registration and invalidation flows.
• Your team is small and the alternative is a bespoke APNs/FCM client with two credential pipelines to maintain.

Look elsewhere when:

• The stack is Laravel — this bundle's Symfony DI, configuration, and service wiring will not plug in.
• Push is a growth or marketing surface: you need templates, segmentation, scheduling, A/B tests, or funnel analytics. Buy a purpose-built platform or build around FCM/APNs directly.
• You need deep native payload control — silent/data-only pushes, rich media, notification actions, or precise collapse/priority semantics that SNS's abstraction flattens.
• Vendor neutrality is a hard requirement, or you expect to move off AWS.
• Support and longevity risk is unacceptable: 40 stars and no dependents means effectively one maintainer. Last release (Feb 2025) is current, which is reassuring, but the bus factor is 1.
• Volume is very high and cost-sensitive — at scale, direct APNs/FCM (free) can beat per-publish SNS fees.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Symfony bundle that lets us ship push notifications to iOS, Android, and web through one AWS service instead of three separate integrations. It is actively maintained (released February 2025) and low-cost to run. The trade-off is dependency on AWS for a user-facing channel and reliance on a low-adoption open-source component — mitigated by the fact that it's a thin wrapper we could replace or fork in days. Recommendation: adopt for transactional notifications only; do not treat it as our marketing-messaging platform.

For engineering: Expect a thin Symfony bundle over aws/aws-sdk-php, exposing SNS publish plus platform-endpoint (device token) management via DI configuration. It is not a Laravel package — Laravel teams should read it as a design reference and use the AWS SDK or a native notification channel instead. Risks to plan around: single maintainer, no downstream dependents, and SNS's abstraction limiting native APNs/FCM payload features. Mitigations: pin the version, wrap it behind our own notification interface so the SNS dependency is swappable, and budget a fork-and-own fallback.

Ask: Approve a time-boxed spike to validate payload fidelity (silent push, deep links, badge counts) against our client requirements before committing to a production integration.