Sms Laravel Package

Technical Evaluation

Architecture fit. tencentcloud/sms is not a Laravel package — it is a thin, auto-generated transport client for the Tencent Cloud SMS API (sms.tencentcloudapi.com, API version 2021-01-11). It ships SmsClient, request/response models (SendSmsRequest, SendStatusSet), and delegates signing, retries, and HTTP to tencentcloud/common on top of Guzzle. That makes it a good fit only if we treat it as an infrastructure adapter at the edge of the domain, not as a service we call throughout the codebase. The correct architecture is a SmsSender contract in our application layer with a TencentSmsTransport implementation behind it, bound via a Laravel service provider — mirroring how Laravel's own MailManager isolates drivers. Anything that lets TencentCloud\Sms\... classes leak into controllers, jobs, or notifications is an architectural smell we should reject in review.

Integration feasibility. Mechanically trivial: composer require tencentcloud/sms, instantiate Credential with SecretId/SecretKey, configure HttpProfile with the regional endpoint, build a SendSmsRequest (SdkAppId, SignName, TemplateId, TemplateParamSet, PhoneNumberSet), call SendSms. Perhaps 40 lines of glue. The genuine critical path is not code — it is Tencent Cloud onboarding: account verification, SMS signature (签名) and template (模板) registration and approval, which for mainland China requires business-entity documentation and can take days and multiple rejection cycles. International SMS is a separate product surface with different template rules and destination-country restrictions. Plan the project around the compliance lead time, not the SDK.

Technical risk. Medium, concentrated in three places. (1) Lock-in at the wrong layer — if the SDK's request models become our internal contract, swapping to Aliyun/Twilio later means touching every call site. (2) Synchronous blocking I/O — SendSms is a synchronous Guzzle call; invoked inline in a request it adds hundreds of milliseconds and couples user latency to a third-party SLA. (3) Partial-failure semantics — a successful API response can still contain per-number failures in SendStatusSet; teams that only catch exceptions will silently drop messages. Secondary risks: the split repo drifts from the tencentcloud-sdk-php monorepo, and Guzzle/PHP version constraints may collide with the host app.

Key questions.

• Which regions and destinations (mainland China, HK, international) must we support at launch, and are signatures/templates already approved or is that on the critical path?
• What is our expected peak volume and required QPS uplift over the default account quota?
• Do we need delivery receipts (status callbacks) and inbound replies, or is fire-and-forget sufficient?
• Is there a regulatory/data-residency requirement forcing message content through Tencent versus a multi-vendor strategy?
• Who owns the Tencent Cloud account, billing, and the SecretId/SecretKey rotation policy — platform team or product team?

Integration Approach

Stack fit. Works with Laravel 8–11 on PHP 7.4/8.x provided the pinned SDK version tolerates our PHP and Guzzle 7 constraints — verify this first, since older SDK releases carry tight or stale tencentcloud/common requirements that can conflict with a modern Laravel lockfile. No service provider, no facade, no config publishing, no .env conventions: all of that is ours to write.

Migration path. Introduce a SmsSender interface (send(string $to, string $template, array $params): SmsResult) plus a DTO carrying per-recipient status. Implement TencentSmsTransport that owns credential construction and request mapping; bind it in a dedicated SmsServiceProvider; expose config through config/sms.php reading TENCENT_SMS_SECRET_ID, TENCENT_SMS_SECRET_KEY, TENCENT_SMS_SDK_APP_ID, TENCENT_SMS_SIGN_NAME, TENCENT_SMS_REGION. Add a log driver selected in local/CI so developers never need live credentials, and so tests assert on the interface rather than mocking SDK internals. Route all sends through queued jobs with retryUntil/backoff — never inline. If we already send mail or push, model this alongside those channels rather than inventing a parallel abstraction.

Compatibility. Region-specific endpoints must be configurable, not hardcoded; the SDK's model classes are versioned by API date (V20210111) and will churn. Keep the SDK version pinned and upgrade deliberately. If inbound callbacks are in scope, be aware the SDK gives no webhook verification helper — signature validation is hand-rolled.

Sequencing.

1. Kick off account verification, signature, and template submissions (longest lead time — do this in week one, in parallel with everything else).
2. Land the SmsSender contract, config, log driver, and tests with no vendor code.
3. Implement and integration-test the Tencent transport against a sandbox/low-volume live account.
4. Wrap in queued jobs, add failure classification and logging.
5. Add observability, then a second driver only if the multi-vendor requirement is confirmed.

Operational Impact

Maintenance. Treat this repo as a build artifact, not a community project. It is split from the tencentcloud-sdk-php monorepo, so GitHub stars, issue activity, and dependent counts here are near-meaningless — the 1 star / 0 dependents / 0.005 score reflect the split-package mechanics, not adoption. Assess health via the parent SDK's release cadence and changelog, pin exact versions, and watch the monorepo for breaking model changes. Budget a small recurring cost for SDK bumps and template edits.

Support. No meaningful GitHub support channel. Escalation is through Tencent Cloud support tickets under our account tier, primarily Chinese-language documentation. That is a real operational constraint: our on-call runbook must include the console URLs, error-code lookup, and the vendor ticket path, and we should assume a language/timezone gap in incident response.

Scaling. The API accepts batched recipient sets per request (up to 200 numbers), so throughput is a function of request concurrency and account QPS quota, not per-message calls. Default quotas are low; request an uplift ahead of any launch with volume. Queue workers with bounded concurrency and exponential backoff on RequestLimitExceeded are mandatory. Cost scales per message with country-specific pricing — international destinations are materially more expensive and need per-country budgeting and abuse controls (rate limits per user, per-IP, per-campaign).

Failure modes. Expect: throttling errors surfaced as exceptions; auth failures from expired/rotated keys or IP allowlists; signature/template-not-approved rejections that only appear at send time; and — most dangerous — HTTP 200 responses containing per-number failures for invalid numbers, carrier blocks, or content filtering. A naive implementation reports "sent" for messages that never left. Instrument both dimensions: exception rate and the failure-code distribution inside SendStatusSet. Also guard against credential leakage (keys in .env only, never in logs), duplicate sends on job retry (carry an idempotency key), and silent queue backlog. Without these, the first production incident will be "users say they never got the code" with green dashboards.

Ramp-up. Low for any PHP developer — the SDK surface is small and the call pattern is documented. The real ramp-up is organizational: learning Tencent's template-approval workflow, error-code taxonomy, and quota-request process. Estimate one engineer-week for the transport plus tests, and two to three calendar weeks for compliance onboarding if signatures and templates are not already in place. Keep a second engineer briefed on the console so credential rotation and template edits are not single-person dependencies.