Turbosms Bundle Laravel Package

Technical Evaluation

Architecture fit — poor. sunra/turbosms-bundle is a Symfony2 bundle (SunraTurbosmsBundle), not a Laravel package. It is built around Symfony's kernel/DI conventions: a DependencyInjection/*Extension class, a Configuration tree, service definitions injected into the Symfony container, and likely a services.xml/services.yml. Laravel has no bundle registry — integration would require the package's service definitions to be re-expressed as a ServiceProvider with bindings and a publishable config file. In practice, you install nothing and rewrite the ~200–400 line wrapper.

Integration feasibility — low directly, moderate indirectly. The bundle's real substance is a thin adapter over the TurboSMS SOAP gateway (token auth, sendSMS, getMessageStatus, getBalance). That contract is easily reproduced with Laravel's Http client or a small SoapClient wrapper. Estimated port effort: 2–4 engineer-days including tests, versus an open-ended cost of forcing a 2016 Symfony package into a modern Laravel container.

Technical risk — high.

• Abandonment: last release 2016-08-24. No PHP 8.x compatibility work, no security patching, no PSR-4 modernization guarantees.
• Composer conflict: Laravel 9/10/11 depend on Symfony 6/7 components. A Symfony 2.x-era bundle's symfony/framework-bundle constraint will either be unsatisfiable or force a dependency downgrade cascade. This is a hard blocker, not a nuisance.
• No social proof: 1 star, 0 dependents, score 0.065. Zero signal of production use; no community to absorb bugs.
• Runtime coupling: may require ext-soap, which is not universal in containerized PHP-FPM images.
• Credential handling: 2016-era Symfony config conventions typically encouraged credentials in config.yml/parameters.yml — an anti-pattern against Laravel's .env + config/services.php discipline.

Key questions before any decision:

1. Is TurboSMS still a required provider, or can we standardize on Twilio/Vonage/MessageBird via Laravel's first-party notification channels?
2. Does TurboSMS now expose a REST/JSON v2 API, or is SOAP still mandatory?
3. Which Laravel and PHP versions are in scope, and is ext-soap available in our base image?
4. Do we need delivery receipts, alpha-name (sender ID) registration, Cyrillic/Unicode segmentation, and batch sends — or only fire-and-forget transactional SMS?
5. What monthly volume and per-request latency budget? (Determines queue design.)
6. Is there a maintained PHP SDK for TurboSMS we could wrap instead?

Verdict: Do not adopt as a dependency. Treat the repository as a reference specification for the TurboSMS API contract and reimplement the client natively.

Integration Approach

Stack fit. There is no fit as-is. Recommended pattern is extract, don't install:

• app/Services/Sms/TurboSmsClient.php — wraps Illuminate\Support\Facades\Http (or SoapClient if SOAP is unavoidable), reads config('services.turbosms.*').
• app/Services/Sms/TurboSmsMessage.php — value object (recipients, body, sender, unicode flag).
• app/Notifications/Channels/TurboSmsChannel.php — implements send() against a TurboSmsMessage, registered via Notification::extend or a via() channel string.
• TurboSmsServiceProvider — binds the client as a singleton; credentials sourced from .env (TURBOSMS_TOKEN, TURBOSMS_SENDER).
• Queue the send via ShouldQueue; never call the gateway inline in a web request.

Migration path. There is no data to migrate — the bundle defines no entities, tables, or migrations. Migration is purely code-level and can be done greenfield: the Laravel implementation replaces the bundle before it is ever installed. If a legacy Symfony service is already using it, the two implementations can coexist behind a shared interface, but there is no reason to bring the bundle into the Laravel codebase.

Compatibility. This is the decisive constraint. Verify before sprint commitment:

• PHP version floor of the bundle vs. our runtime (expect PHP 5.6/7.0 idioms — no return types, no nullable syntax, possibly removed functions).
• symfony/framework-bundle constraint vs. Laravel's transitive Symfony version. Expect composer require to fail or propose destructive downgrades.
• ext-soap availability across local, CI, and production images.
• Autoloading standard (PSR-0 vs PSR-4) if any code is vendored.

Sequencing.

1. Confirm TurboSMS account, API generation, and whether REST is available (1 day, no code).
2. Spike a single raw send in php artisan tinker — validates auth, payload shape, response codes (½ day).
3. Build client + DTO + unit tests against recorded fixtures (1–2 days).
4. Add notification channel, queue job, retry/backoff policy, and structured logging (1 day).
5. Ship behind a feature flag; shadow-send to a test number; compare against legacy provider output.
6. Document the contract and decommission any bundle reference from the repo.

Operational Impact

Maintenance. We inherit full ownership of a ~300-line integration. That is a feature, not a cost — an internally owned client tracks our PHP version, our logging, and our testing conventions, whereas the upstream package will never receive another commit. Budget a small recurring allowance for TurboSMS API changes (they are infrequent) and provider contract renewals.

Support. No upstream maintainer, no issue tracker activity since 2016, no security disclosure channel. Escalation is entirely internal plus TurboSMS's own account support. This must be documented in the service's runbook: named owner, escalation path, provider account contacts.

Scaling. Throughput is bounded by TurboSMS rate limits and per-message cost, not by the package. Design implications:

• Queue all sends; use a dedicated queue/worker pool so SMS latency never touches the request path.
• Batch where the API supports it, but respect provider batch-size caps.
• Segment length matters: Cyrillic forces UCS-2 encoding at 70 chars/segment vs. 160 for GSM-7 — cost and UX both scale with segment count. Enforce this in the value object, not the caller.
• Track balance via a scheduled health check (getBalance) and alert on low credit — a classic silent-failure mode for SMS.

Failure modes to design against.

• HTTP 200 with an error code in the body. TurboSMS-style gateways commonly return transport success plus an application-level status. Parse the body, not just the status code.
• Silent partial failures in multi-recipient sends — map per-recipient results and surface them.
• Token expiry / rotation — externalize credentials, fail loudly, alert.
• No retry logic in a 2016-era synchronous wrapper — implement exponential backoff with a dead-letter path, and an idempotency key to prevent duplicate SMS on retry (duplicate SMS is a real customer-visible and billable defect).
• Unicode/segmentation miscalculation — over-length messages get split and billed multiplicatively.
• Provider outage — degrade gracefully; SMS is usually a secondary channel, so log-and-drop with alerting rather than blocking the primary flow.

Ramp-up. Low technical complexity: the integration surface is four or five methods. Any mid-level Laravel engineer can own it within a sprint given the documented API contract. The genuine risk is knowledge concentration around TurboSMS's quirks (encoding rules, alpha-name approval, response-code semantics), which is mitigated by tests-as-documentation and a short ADR capturing why the bundle was rejected in favor of a native client.