- Does this bundle work with Laravel 10+ and PHP 8.1+?
- Yes, the bundle requires PHP 8.1+ and Laravel 10+ (due to Symfony 6.2 dependencies like `symfony/http-client`). Ensure your project meets these requirements, as older versions won’t support the underlying Symfony components. Laravel’s built-in Symfony bridge handles compatibility, but test thoroughly in your environment.
- Can I use multiple SMS providers (e.g., Twilio, AWS SNS) with this bundle?
- No, the bundle is tightly coupled to Eskiz’s `SmsSender` class with no abstraction layer. To support multiple providers, you’ll need to wrap `SmsSender` behind an interface (e.g., `SmsGatewayInterface`) and implement adapters for each provider. This requires custom code but avoids vendor lock-in.
- How do I send an SMS in a Laravel controller or command?
- Inject the `SmsSender` class into your controller or command constructor via Laravel’s dependency injection. Call `$sender->sendMessage('phone_number', 'message')`. Example: `public function __construct(private SmsSender $sender) { $this->sender->sendMessage('998123456789', 'Hello'); }`. No Facade is provided, so manual injection is required.
- Is there built-in support for async SMS sending (e.g., queues) or retries?
- No, the bundle doesn’t include async or retry logic. To implement this, wrap `SmsSender` in a Laravel queue job (e.g., `SendSmsJob`) and use Laravel’s queue system with retries. Add middleware like `retry:3` to the job for resilience. This is a manual but straightforward extension.
- How do I configure the bundle for production? Are credentials secure?
- Credentials (e.g., `ESKIZ_EMAIL`, `ESKIZ_PASSWORD`) are stored in `.env`, which Laravel already handles securely. For production, use Laravel’s `config/sms.php` to centralize settings and avoid hardcoding. Rotate credentials via environment variables and mask them in logs using Laravel’s `Log::mask()` or a package like `monolog-masker`.
- What if Eskiz’s API changes or goes down? How do I handle errors?
- The bundle lacks built-in error handling for Eskiz API failures (e.g., rate limits, invalid responses). Add middleware to the `SmsSender` HTTP client (e.g., Symfony’s `RetryStrategy`) or use Laravel’s `retry()` helper. Log failures with `Log::error()` and implement fallback providers if critical (e.g., via a decorator pattern).
- How do I test SMS functionality in CI without hitting Eskiz’s API?
- Mock the `SmsSender` class using PHPUnit’s `createMock()` or a test double. Replace the real sender with a mock in your test’s service container binding (e.g., `app()->bind(SmsSender::class, fn() => $this->mockSender)`). Use `symfony/http-client` mocks if testing HTTP responses. Avoid real API calls in CI to prevent costs or rate limits.
- Are there alternatives to this bundle for Laravel SMS?
- Yes, consider `laravel-notification-channels/sms` for multi-provider support (Twilio, Nexmo, etc.) with built-in queues and events. For Eskiz-specific needs, you could also integrate directly via the Eskiz API with Laravel’s `Http` client, though this lacks the bundle’s modularity. Evaluate your need for abstraction vs. simplicity.
- Does the bundle support phone number validation or formatting?
- No, the bundle doesn’t validate phone numbers or format them for Eskiz’s API. Add validation using Laravel’s `Validator` facade or a library like `libphonenumber`. For Eskiz-specific formatting, check their API docs and preprocess numbers before sending. Example: `Validator::make(['phone' => $number], ['phone' => 'required|phone:UZ'])`.
- How do I log SMS success/failure metrics for observability?
- Extend the `SmsSender` class to log events (e.g., `Log::info('SMS sent to: '.$phone)`) or emit events (e.g., `event(new SmsSent($phone, $message))`). Use Laravel’s `Log` channel or a monitoring tool like Sentry/Datadog. For structured logs, serialize responses and store them in a database table for auditing.