Smsapi Notifier Laravel Package

Technical Evaluation

Architecture Fit

• Symfony Integration: The package is designed for Symfony Notifier, which may require additional abstraction layers in Laravel. If the Laravel app already uses Symfony components (e.g., spatie/laravel-symfony-messenger), integration is moderate-effort. Otherwise, a custom wrapper is needed.
• Laravel Compatibility: Not natively Laravel-first, but can be adapted via:
  • Service Providers (for DI).
  • Facades (for cleaner syntax).
  • Event Listeners (for async workflows).
• Use Case Alignment:
  • Transactional SMS (OTPs, alerts) → High fit.
  • Bulk SMS campaigns → Low fit (SMSAPI may lack volume discounts).
  • Two-way SMS → No fit (package is one-way only).

Integration Feasibility

• Dependencies:
  • Requires Symfony Notifier (^6.0), which may introduce dependency bloat if unused elsewhere.
  • SMSAPI API key management must be handled via Laravel’s .env or a secrets manager.
• Configuration:
  • DSN format (smsapi://TOKEN@endpoint?from=SENDER) must be mapped to Laravel’s config (e.g., config/services.php).
  • Test mode (?test=1) should be environment-aware (e.g., APP_ENV=testing).
• Event-Driven Workflows:
  • Symfony Notifier’s events (e.g., MessageSentEvent) can be mapped to Laravel’s events/queues via:

    // Example: Listen to SMS sent events
    public function handle(MessageSentEvent $event) {
        if ($event->getMessage() instanceof SmsMessage) {
            event(new SmsSent($event->getMessage()));
        }
    }
    

Technical Risk

Key Questions

1. Is Symfony Notifier already in the stack?
   • If no, weigh the cost of adding it vs. a custom SMSAPI client.
2. What’s the SMS delivery SLA?
   • SMSAPI’s "fast" mode costs more; ensure alignment with business needs.
3. Are there existing SMS providers?
   • Avoid provider fragmentation; consolidate if possible.
4. How are failures handled?
   • Ensure retries, dead-letter queues, and alerts (e.g., Slack/Sentry).
5. Is SMSAPI’s PHP SDK needed?
   • Direct SDK use may offer more control (e.g., webhooks, advanced features).

Integration Approach

Stack Fit

• Ideal Stack:
  • Laravel + Symfony Notifier (spatie/laravel-notifier) + Symfony Messenger.
  • Apps using queues (e.g., Laravel Horizon) for async SMS delivery.
• Alternative Stacks:
  • Pure Laravel: Use a custom SMSAPI client (Guzzle-based) with Laravel’s Bus facade.
  • Lumen: Similar to Laravel but with simplified DI.

Migration Path

1. Phase 1: Assessment (1–2 days)
   • Audit existing SMS logic (e.g., manual HTTP calls, third-party services).
   • Decide: Adopt Symfony Notifier or build a custom client.
2. Phase 2: Setup (2–3 days)
   • Option A (Symfony Notifier):
     • Install dependencies:

       composer require symfony/notifier symfony/smsapi-notifier
       

     • Configure .env:

       SMSAPI_DSN=smsapi://TOKEN@api.smsapi.com?from=SENDER&test=${APP_ENV:=local}
       

     • Create a Symfony Notifier transport:

       // config/services.php
       'smsapi' => [
           'dsn' => env('SMSAPI_DSN'),
       ],
       

   • Option B (Custom Client):
     • Create a SmsapiService class (Guzzle-based) and bind to Laravel’s container.
3. Phase 3: Integration (3–5 days)
   • Replace legacy SMS logic with Symfony SmsMessage or custom client calls.
   • Example:

     // Using Symfony Notifier
     $message = new SmsMessage('Your code: 12345', 'Recipient');
     $notifier->send($message);
     
     // Using Custom Client
     $smsapi->send('+1234567890', 'Your code: 12345');
     

4. Phase 4: Testing (2–3 days)
   • Test delivery success/failure scenarios.
   • Mock SMSAPI responses in Pest/Unit tests:

     $mock = Mockery::mock('overload', SMSAPI::class);
     $mock->shouldReceive('send')->andReturn(true);
     

Compatibility

• Laravel Versions: Compatible with Laravel 10+ (PHP 8.1+).
• Symfony Versions: Requires Symfony 6.0+ (if using Notifier).
• SMSAPI Endpoints: Supports both smsapi.pl and smsapi.com.

Sequencing

1. Start with low-risk use cases (e.g., OTPs).
2. Gradually migrate high-priority SMS workflows (e.g., transaction alerts).
3. Monitor costs via SMSAPI dashboard or custom logging.

Operational Impact

Maintenance

• Dependency Updates:
  • Monitor Symfony Notifier and SMSAPI API changes.
  • Use Composer scripts to auto-update dependencies:

    composer require symfony/notifier:^6.4 symfony/smsapi-notifier:^7.4
    

• Configuration Drift:
  • Centralize SMSAPI credentials in Laravel Forge/Vault or .env.
  • Use environment variables for test=1 in development.

Support

• Debugging:
  • Enable SMSAPI debug logs via DSN:

    SMSAPI_DSN=smsapi://TOKEN@api.smsapi.com?from=SENDER&debug=1
    

  • Use Laravel Log to track failures:

    try {
        $notifier->send($message);
    } catch (\Exception $e) {
        Log::error("SMS failed: " . $e->getMessage());
    }
    

• Vendor Lock-in:
  • Mitigation: Abstract SMSAPI calls behind a service interface:

    interface SmsService {
        public function send(string $to, string $message): bool;
    }
    

Scaling

• Performance:
  • Queue SMS delivery (e.g., Laravel Horizon) to avoid timeouts.
  • Batch sends for bulk operations (if SMSAPI supports it).
• Cost Optimization:
  • Use SMSAPI’s "eco" mode (no from= parameter) for cheaper deliveries.
  • Set rate limits in Laravel’s config/queue.php.

Failure Modes

Ramp-Up

• Onboarding Time:
  • Developers: 1–2 days to integrate (if using Symfony Notifier).
  • Non-technical teams: 30 mins to configure .env and test.
• Training Needs:
  • Symfony Notifier basics for devs unfamiliar with the component.
  • SMSAPI dashboard for monitoring usage/costs.
• **Document