Sms Laravel Package

Technical Evaluation

Architecture fit: shetabit/sms is a Laravel-native notification/transport package that abstracts Iranian SMS gateways behind a driver interface. v1.1.0 adds an IPPanel driver contributed by a first-time contributor (@MahdiGraph, PR #2). For a TPM, the significance is not the driver itself but what it confirms: the package is a thin, driver-plugin architecture (config file → driver class → send/sendBulk contract), which fits cleanly into a Laravel service container and is trivially mockable behind an interface. This is the right shape for TPMs who want a stable internal SmsSender seam rather than vendor SDK calls scattered through controllers.

Integration feasibility: Low effort. Install via Composer, publish the config, select the driver, supply credentials. No schema, no queue worker changes, no new infrastructure. The IPPanel addition means teams already standardizing on IPPanel can adopt the package without forking or writing a custom driver wrapper — this removes a previously common blocker.

Technical risk: Moderate but bounded, concentrated in three areas:

1. Single-maintainer / low-bus-factor project. PR #2 being a first external contribution tells you the contributor base is thin. Vendor risk is real; treat this as a library you may need to patch, not a strategic dependency.
2. Region-specific gateway coverage. Drivers target Iranian providers (IPPanel, Kavenegar, etc.). Evaluate only against the providers you actually contract with; the abstracted interface is the value, not the driver count.
3. Semantic versioning discipline. A minor bump adding a driver is a correct semver call (additive, no contract change), which is a positive signal for upgrade safety. But it also means the release notes are the only signal — no changelog depth on whether the driver contract was touched.

Key questions to ask engineering:

• Does the new IPPanel driver conform to the existing driver contract, or did it require interface changes that could affect our custom drivers?
• Are IPPanel credentials/config keys namespaced so they cannot collide with an existing driver config?
• Do we have our own thin wrapper around the package so a driver swap (or a package abandonment) is a one-file change?
• Does the driver support bulk/pattern sends, or only single-message send? Our product may need templates.
• Is there test coverage on the new driver, or is it untested community code we'd be trusting in a production send path?

Integration Approach

Stack fit: Requires Laravel (service provider + facade + config publish). If we are on Laravel 9/10/11, integration is idiomatic; the package slots in beside our existing notification channel rather than replacing it. It should sit behind our own SmsService wrapper, not be called directly from domain code.

Migration path: Two viable routes.

• Greenfield: install, configure IPPanel, ship. One sprint-day of work including credentials rotation and a staging smoke test.
• Existing hardcoded gateway calls: introduce the package behind our wrapper interface first, route one low-risk notification flow through it, then migrate remaining call sites incrementally. Avoid a big-bang rewrite of every send() call.

Compatibility: The v1.0.0 → v1.1.0 delta is additive only (new driver, new config keys). No breaking changes, no deprecations. Any code pinned to ^1.0 will accept 1.1.0 automatically on composer update — decide deliberately whether to allow that (recommended: yes, but pin and test).

Sequencing:

1. Pin the version explicitly (1.1.0) rather than floating.
2. Land config + wrapper interface + a queued, retryable send job.
3. Staging validation against IPPanel sandbox/real credentials with a delivery-receipt check — "sent" from the API is not "delivered" to the handset.
4. Production rollout to one notification type, observe delivery rate and error logs for a week.
5. Expand to remaining flows; only then remove legacy gateway code.

Operational Impact

Maintenance: The main ongoing cost is ownership of a low-activity OSS dependency in a transactional send path — i.e. something that fails in front of users. Budget for: watching the repo for releases, a quarterly composer audit/outdated check, and the assumption that we may need to vendor-patch the IPPanel driver ourselves if it breaks against an API change. Because the driver is community-contributed and new, treat it as "works today, unproven at scale" and keep our wrapper authoritative.

Support: The project has no commercial support tier, one primary maintainer, and a contributor who has just made their first contribution. Escalation path is "open an issue" — not acceptable as our sole fallback for a customer-facing notification channel. Mitigation: our wrapper + a documented manual fallback (direct IPPanel API call or a second driver) so an upstream bug is a config change, not an incident.

Scaling: SMS volume scaling is a property of the gateway, not the package. The package adds negligible overhead. Real scaling concerns are (a) queueing — sends must go through Laravel queues with backoff/retry, not synchronous in-request, or a slow gateway will hang user requests; (b) rate limits and throughput — IPPanel plan limits, not PHP, will be the ceiling; (c) bulk sends — verify before relying on it for campaigns.

Failure modes to design for:

• Gateway returns 200 but message is undelivered (silent failure) — need delivery-status polling, not just send confirmation.
• Credential expiry / IP allowlist change at the provider — surface as a distinct alertable error class, not a generic exception.
• Package abandoned or IPPanel API changes shape — wrapper isolates the blast radius to one class.
• Queued job retries causing duplicate SMS on timeout-after-success — needs idempotency keys or a dedupe window. This is a cost and user-trust issue, not just a technical one.
• Config key collisions if multiple drivers are configured simultaneously.

Ramp-up: Very low for a Laravel developer — half a day to read the driver interface and config, a day to build the wrapper and first flow. The expensive knowledge is provider-side (IPPanel account setup, sender lines, template approval, delivery reporting), not package-side. Assign that to whoever owns vendor relationships, and ensure credentials are in the secret manager, not the published config file.