flc/alidayu
flc/alidayu is a Laravel package for integrating Alibaba’s Alidayu SMS service, making it easy to send verification codes and notifications through a simple, configuration-driven API with service provider and facade support.
Architecture fit. flc/alidayu is a thin PHP SDK wrapper over Alidayu's (阿里大于/阿里鱼) RPC-style API for SMS, voice, and notification sends. It follows Laravel's conventional shape — a service provider binding a client into the container plus a config block (AppKey/AppSecret/format/region) — so it slots into config/services.php and the Facade pattern without touching framework internals. Zero-ceremony fit for a Laravel 5.x-era application.
Integration feasibility. The call surface is small: typically one send method taking a template code, template params, and recipient number. That makes a first integration quick, but the SDK stops at the transport boundary — it does not provide queueing, retry policy, rate limiting, delivery-receipt handling, or a Laravel Notification channel. Every one of those has to be built around it, which is where most of the real effort lands.
Technical risk. High. Three compounding factors:
Key questions. Is the target environment genuinely still on Alidayu, or has it silently migrated to Aliyun? What Laravel/PHP versions are in scope? Is SMS auth-critical (OTP) or best-effort (marketing)? Is there a secondary provider for failover? Who owns the AccessKey rotation and template-approval process?
Stack fit. Clean on Laravel 5.x / PHP 7.x. On Laravel 9–11 and PHP 8.2+, expect friction — container binding signatures, Facade registration, and PHP 7.0-style code may not resolve cleanly. Validate with a throwaway composer require before committing to a design.
Migration path. Do not let the SDK leak into domain code. Define an internal SmsGateway interface (or a Laravel Notification channel) and implement two drivers behind it: LegacyAlidayu wrapping this package, and AliyunDysmsapi wrapping the official alibabacloud/dysmsapi-20170525 SDK. Select via config so environments can diverge.
Compatibility. Pin PHP constraints explicitly. Confirm ext-curl / ext-json. Audit for global function calls and hard-coded endpoints — legacy Alidayu hosts are the most likely thing to break first.
Sequencing. (1) Introduce the interface with a null/log driver so call sites stabilize. (2) Wrap the legacy SDK as driver #1. (3) Build the Aliyun driver in parallel. (4) Shadow-send in staging and diff responses. (5) Flip the primary to Aliyun, keep legacy as fallback. (6) Remove the legacy dependency and its config.
Maintenance. Effectively orphaned. No upstream fixes, so any CVE, PHP-version break, or endpoint change is yours. Budget for a vendored fork if the dependency becomes load-bearing; otherwise treat it as disposable glue.
Support. Chinese-language documentation, community-only, no SLA. On-call engineers must read Alidayu/Aliyun error codes directly — the SDK surfaces raw codes without much interpretation.
Scaling. The SDK is synchronous; always dispatch behind queued jobs. Expect per-minute and per-day send quotas, template whitelists, and signature registration — so implement token-bucket rate limiting and exponential backoff at the wrapper layer, not inside the SDK.
Failure modes. Most probable: endpoint deprecation, expired/invalid AccessKey, unapproved template or signature mismatch, per-number throttling, carrier-side filtering, and "HTTP 200 with a business error code" responses that look successful to naive callers. Instrument delivered-vs-accepted metrics separately and capture raw responses.
Ramp-up. Low to learn the API (a day), moderate to learn the compliance workflow (template/signature approval, real-name verification). Realistically a 1–2 sprint integration for a peripheral feature; significantly more if OTP is auth-critical and needs failover, audit logging, and provider abstraction from day one.
How can I help you explore Laravel packages today?