Symfony Turbosms Laravel Package

Technical Evaluation

Architecture Fit

• Legacy Symfony2/3 Bundle: The package is a Symfony2/3-specific bundle, meaning it is tightly coupled to the Symfony framework and its dependency injection (DI) container. This limits its applicability in modern Laravel ecosystems unless abstracted via a facade or adapter layer.
• SOAP-Based SMS Gateway: Relies on Turbosms.ua’s SOAP API, which is outdated compared to modern REST/gRPC APIs. This introduces technical debt in terms of API reliability, security (SOAP lacks built-in security standards like OAuth), and maintainability.
• Database Dependency: Hardcodes schema updates for SMS logging, which may conflict with Laravel’s Eloquent or migrations. Requires manual schema adjustments or a custom adapter.

Integration Feasibility

• Laravel Compatibility: Low—direct integration is impossible without significant refactoring. The bundle assumes Symfony’s ContainerInterface, EventDispatcher, and Doctrine ORM, none of which are native to Laravel.
• PHP Version Support: Requires PHP ≥5.4, which is non-restrictive but lacks modern PHP features (e.g., typed properties, attributes).
• Dependency Conflicts: May clash with Laravel’s service container (e.g., Symfony\Component\DependencyInjection) unless isolated via a proxy layer.

Technical Risk

• SOAP Deprecation: Turbosms.ua’s SOAP API may be discontinued or replaced with REST. The package offers no fallback mechanism.
• Security Risks:
  • Hardcoded credentials in config.yml (no environment variable support).
  • No input validation for SMS content (risk of injection or malformed requests).
• Maintenance Burden:
  • Last release in 2017—no updates for Symfony 4/5/6 or Laravel compatibility.
  • Undocumented error handling (e.g., SOAP faults, rate limits).
• Testing Gaps: No tests, no CI/CD pipeline, and no community adoption (1 star, low score).

Key Questions

1. Why SOAP? Is Turbosms.ua’s SOAP API the only viable option, or can we switch to a modern REST API (e.g., Twilio, AWS SNS)?
2. Credential Management: How will credentials be secured (env vars, vault, or Symfony’s parameter bag)?
3. Database Schema: Will Laravel’s migrations or Eloquent models replace the Doctrine schema, or will we use a separate table?
4. Error Handling: What’s the fallback for failed SMS deliveries (retries, dead-letter queue, notifications)?
5. Long-Term Viability: Is this a temporary solution, or will we invest in a Laravel-native SMS package (e.g., nesbot/carbon for time-based retries + a custom HTTP client)?

Integration Approach

Stack Fit

• Laravel Unfriendly: The bundle is Symfony-centric and requires workarounds to fit Laravel’s architecture:
  • Service Container: Laravel’s Illuminate\Container ≠ Symfony’s ContainerInterface. A facade or adapter class would bridge the gap.
  • Doctrine ORM: Laravel uses Eloquent. The SMS log table could be mapped via Eloquent or a raw query.
  • Routing/Controller: Symfony’s @Route annotations won’t work; Laravel uses Route::get() or controller methods.
• Alternative Stacks:
  • Symfony Projects: Ideal fit with minimal changes.
  • Legacy PHP Apps: Possible with a lightweight wrapper, but not recommended.

Migration Path

1. Option 1: Abandon the Package (Recommended)

   • Replace with a Laravel-compatible SMS service (e.g., php-sms/sms for HTTP clients or a custom Guzzle-based solution).
   • Example:

     // Laravel Service Provider
     $client = new Client(['base_uri' => 'https://api.turbosms.ua/soap']);
     $response = $client->post('/send', [
         'body' => ['login' => env('TURBOSMS_LOGIN'), 'message' => $sms]
     ]);
     

   • Pros: Modern, maintainable, no Symfony dependency.
   • Cons: Requires reimplementing SOAP logic.

2. Option 2: Symfony-Laravel Bridge (High Effort)

   • Step 1: Extract the SOAP client logic from the bundle into a standalone PHP class (e.g., TurbosmsSoapClient).
   • Step 2: Create a Laravel service provider to register the client and a facade:

     // app/Providers/TurbosmsServiceProvider.php
     public function register() {
         $this->app->singleton('turbosms', function () {
             return new TurbosmsSoapClient(
                 env('TURBOSMS_LOGIN'),
                 env('TURBOSMS_PASSWORD')
             );
         });
     }
     

   • Step 3: Replace Doctrine logging with Eloquent:

     // app/Models/SmsLog.php
     class SmsLog extends Model {
         protected $fillable = ['phone', 'message', 'status', 'sent_at'];
     }
     

   • Step 4: Create a Laravel helper to mimic the bundle’s send() method:

     // app/Helpers/SmsHelper.php
     public static function send(string $message, string $phone) {
         $client = app('turbosms');
         $result = $client->send($message, $phone);
         SmsLog::create([...]);
         return $result;
     }
     

   • Pros: Reuses existing SOAP logic.
   • Cons: High maintenance overhead; mixes Symfony/Laravel patterns.

3. Option 3: Hybrid Approach (Symfony Microkernel)

   • Run the bundle in a separate Symfony micro-service (e.g., via Lumen or a Symfony micro-app) and call it via HTTP.
   • Pros: Isolates Symfony dependencies.
   • Cons: Overkill for SMS; adds latency and complexity.

Compatibility

• PHP 8+: The package lacks support for modern PHP features (e.g., typed properties, constructor property promotion). Manual patches would be needed.
• Symfony 4/5/6: The bundle targets Symfony 2/3. Breaking changes in later versions (e.g., DI component updates) would require updates.
• Laravel Services: Conflicts with Laravel’s ServiceProvider/Container if not properly namespaced.

Sequencing

1. Assess API Viability: Confirm Turbosms.ua’s SOAP API is still active and secure.
2. Credential Security: Migrate credentials to Laravel’s .env or a secrets manager.
3. Database Setup: Create an Eloquent model for SMS logs or disable save_to_db if unused.
4. Testing: Mock the SOAP client to test SMS sending without hitting the API.
5. Fallback Plan: Implement a queue system (e.g., Laravel Queues) for retries if the API fails.

Operational Impact

Maintenance

• High Risk: The package is abandoned (no updates since 2017). Any issues (e.g., SOAP API changes) will require manual fixes.
• Dependency Bloat: Pulls in Symfony components unnecessarily, increasing deployment size and potential attack surface.
• Documentation: Nonexistent for Laravel use cases. All integration steps must be reverse-engineered.

Support

• No Community: 1 GitHub star and a 0.305 health score indicate no active support.
• Debugging: SOAP errors (e.g., WSDL parsing, authentication failures) will require deep PHP/Symfony knowledge.
• Vendor Lock-in: Tied to Turbosms.ua’s API; switching providers would require rewriting the SOAP client.

Scaling

• Performance: SOAP is slower than REST/gRPC. High-volume SMS sending may hit rate limits or timeouts.
• Concurrency: No built-in support for parallel requests. Laravel’s queue system would need to be added.
• Monitoring: No native logging or metrics. Would require custom instrumentation (e.g., Laravel’s Log facade).

Failure Modes