Sms Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Monolithic vs. Modular: The package is a Symfony Bundle, designed for tight integration with Laravel (via Symfony’s bridge components). It follows a modular approach by encapsulating SMS functionality in a reusable bundle, which aligns well with Laravel’s service container and dependency injection patterns.
• Coupling: The bundle enforces direct dependency injection (SmsSender in constructor), which is clean but may introduce tight coupling if the SMS provider (Eskiz) becomes a bottleneck or requires future changes.
• Abstraction Layer: The package lacks provider abstraction (e.g., no interface for SmsSender), making it harder to swap providers later. This could lead to vendor lock-in if Eskiz’s API changes or if the team needs to support multiple SMS gateways.
• Event-Driven Potential: No built-in support for asynchronous sending, retries, or event listeners (e.g., SmsSentEvent). This could complicate use cases requiring reliability (e.g., transactional SMS).

Integration Feasibility

• Laravel Compatibility:
  • Requires Symfony 6.2 components, which Laravel 10+ supports via symfony/http-client, symfony/dotenv, etc.
  • PHP 8.1+ is a hard requirement; ensure your Laravel app meets this.
  • No Laravel-specific optimizations (e.g., no ServiceProvider or Facade integration), so manual wiring is needed.
• Configuration Overhead:
  • Hardcodes Eskiz-specific credentials in .env (e.g., ESKIZ_EMAIL, ESKIZ_PASSWORD), which is fine for single-provider setups but inflexible for multi-environment or multi-gateway needs.
  • No validation for phone number formats or API response handling (e.g., rate limits, errors).
• Testing:
  • No mocking support out of the box. Testing SMS logic would require HTTP client mocks (e.g., symfony/http-client mocks) or a test double for SmsSender.

Technical Risk

Key Questions

1. Provider Strategy:
   • Is Eskiz the only SMS provider needed, or should the system support alternatives (e.g., Twilio, AWS SNS)?
   • If multi-provider, how will routing logic (e.g., fallback providers) be implemented?
2. Reliability:
   • Are SMS deliveries critical (e.g., OTPs)? If so, how will retries/timeouts be handled?
3. Observability:
   • How will SMS success/failure metrics be logged or exposed (e.g., to Datadog, Sentry)?
4. Security:
   • Are ESKIZ_PASSWORD and other credentials properly rotated and masked in logs?
5. Testing:
   • How will SMS-dependent workflows be tested in CI (e.g., mocking HTTP calls)?

Integration Approach

Stack Fit

• Laravel Ecosystem:
  • Works with Laravel 10+ (Symfony 6.2 compatibility).
  • Service Container: The bundle leverages Laravel’s DI, so no major conflicts.
  • Queues: Async sending can be added via Laravel Queues (wrap SmsSender in a job).
• Symfony Components:
  • symfony/http-client: Used for Eskiz API calls. Laravel’s Http facade can coexist but may require aliasing.
  • symfony/dotenv: .env support is redundant in Laravel (use Laravel’s .env system instead).
• Alternatives Considered:
  • Laravel Packages: laravel-notification-channels/sms (more mature, supports multiple providers).
  • Standalone: Direct Eskiz API integration (less boilerplate but no bundle benefits).

Migration Path

1. Phase 1: Proof of Concept (PoC)
   • Install the bundle in a staging environment.
   • Replace SmsSender with a test double (e.g., mock Eskiz API responses).
   • Verify basic SMS sending works.
2. Phase 2: Core Integration
   • Replace hardcoded .env with Laravel’s config system (e.g., config/sms.php).
   • Abstract SmsSender behind an interface to enable provider swapping:

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

   • Add retry logic using Laravel’s retry helper or a decorator pattern.
3. Phase 3: Production Readiness
   • Instrument with logging/metrics (e.g., log SMS IDs, delivery status).
   • Implement circuit breakers for Eskiz API failures (e.g., using spatie/fractal).
   • Document provider-specific quirks (e.g., Eskiz’s rate limits).

Compatibility

Sequencing

1. Prerequisites:
   • Upgrade Laravel to 10.x (if not already).
   • Ensure symfony/http-client is installed (Laravel 10+ includes it).
2. Installation Order:
   • composer require amirjon/sms-bundle
   • Register bundle in config/bundles.php.
   • Override .env with Laravel’s config (avoid Symfony’s dotenv).
3. Testing Order:
   • Unit tests → Integration tests (mock HTTP) → End-to-end (real Eskiz API).
4. Deployment Order:
   • Staging (PoC) → Canary (limited users) → Full rollout.

Operational Impact

Maintenance

• Bundle Updates:
  • No auto-updates: Manual composer update required (risk of breaking changes).
  • Backward Compatibility: Unclear; bundle is new (v1.0.0) with no deprecation policy.
• Dependency Bloat:
  • Pulls in Symfony 6.2 components, which may conflict with other packages (e.g., symfony/yaml).
  • Mitigation: Use composer why-not to detect conflicts.
• Provider-Specific Logic:
  • Eskiz API changes (e.g., new auth) will require bundle forks or patches.

Support

• Vendor Support:
  • No official support: Package has 0 stars/dependents; issues must be community-driven.
  • Eskiz Support: Depends on third-party (Eskiz) for API issues.
• Debugging:
  • Limited observability: No built-in logging for SMS lifecycle (sent/delivered/failed).
  • Recommendation: Add middleware to log:

    $sender->send($to, $message); // Log start
    try {
        $response = $sender->send($to, $message);
    } catch (Exception $e) {
        // Log error + retry logic
    }
    

• SLAs:
  • No guarantees: Eskiz’s uptime/SLA must be documented and monitored.

Scaling

• Horizontal Scaling:
  • Stateless: The bundle is stateless (no DB sessions), so scales horizontally.
  • Rate Limits: Eskiz may throttle requests; implement exponential backoff.
• Performance:
  • Synchronous by default: Each send() blocks until Eskiz responds (~100–500ms latency).
  • Optimization: Use Laravel Queues to offload to workers (e.g., Redis queue).
• Cost:
  • Pay-per-SMS: Eskiz pricing must be modeled (e.g., cost per 1000 messages).

Failure Modes